Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 UTC on 18 March 2024, to get $100 off your ticket.
Here's the notice:
Notice: Trying to get property of non-object in /Users/Shared/Localhost/drupal_cvs/includes/session.inc on line 44
Warning: pg_query() [function.pg-query]: Query failed: ERROR: argument of NOT must be type boolean, not type smallint in /Users/Shared/Localhost/drupal_cvs/includes/database.pgsql.inc on line 94
Warning: ERROR: argument of NOT must be type boolean, not type smallint query: SELECT NOT(status) FROM access WHERE type = 'host' AND LOWER('172.16.0.183') LIKE LOWER(mask) ORDER BY status DESC LIMIT 1 OFFSET 0 in /Users/Shared/Localhost/drupal_cvs/includes/database.pgsql.inc on line 113
Comment | File | Size | Author |
---|---|---|---|
#10 | bootstrap.inc_16.patch | 831 bytes | havran |
#5 | bootstrap_pg_error.patch | 815 bytes | Jaza |
#4 | bootstrap.inc_14.patch | 830 bytes | havran |
#3 | bootstrap.inc_13.patch | 862 bytes | havran |
Comments
Comment #1
havran CreditAttribution: havran commentedThis is related in file includes/bootstrap.inc in this function:
NOT() don't work on PostgreSQL (8.1 in my installation) - status need be boolean type but is int2 type... This function need rewrite...
Comment #2
havran CreditAttribution: havran commentedI have done some examination. Correct syntax for both (MySQL and PostgreSQL) is:
But there is another problem - PostgreSQL returns always 't' for true and 'f' for false which is still true after conversion to boolean.
Comment #3
havran CreditAttribution: havran commentedOk i have created patch. Need test in mysql.
Comment #4
havran CreditAttribution: havran commentedI have better patch and i think this it is ANSI92 SQL.
Comment #5
Jaza CreditAttribution: Jaza commentedHere's a simpler way to fix the problem. Works in pgsql and mysql.
Comment #6
havran CreditAttribution: havran commentedHave you tried this patch in real situation? PostgreSQL return 't' or 'f' and (bool) 't' or bool ('f') is still true... (i have tried this on PostgreSQL 8.1 and 7.4). Read this issue - http://drupal.org/node/81078 - is related.
Comment #7
Jaza CreditAttribution: Jaza commented@havran: not sure what you're saying. The statement
SELECT (status = 0)
always returns either a boolean (t/f) or integer (1/0) value (I'm not an expert on which database systems return which type - but I'm pretty sure that they all return one of these two types). I have tested this statement on MySQL 4.1 and PostgreSQL 8.1, and it works great. I really don't see what's wrong with the value that this statement yields.It would be great if you could also fix up http://drupal.org/node/81078 to use the approach that my patch uses (which is the approach that was originally suggested for that issue as well).
Comment #8
havran CreditAttribution: havran commentedOk. Here is real situation.
Comment #9
drummThe last patch posted looks okay. Please reopen if it wasn't. (And do change the issue status if such reviews mean patches are not suitable.)
Comment #10
havran CreditAttribution: havran commentedWith this patch i get always Sorry, 127.0.0.1 has been banned.. I have tried value 0 and value 1 in status column... Real test is real test...
Attached patch work correct.
Comment #11
Dries CreditAttribution: Dries commentedCommitted to CVS HEAD. Thanks.
Comment #12
Dries CreditAttribution: Dries commentedComment #13
Jaza CreditAttribution: Jaza commentedThanks for the clarification, Havran - and good to see that the final patch that was committed was the one that worked best.
However, I think that the issue you pointed out, of pgsql returning a string value of 't' or 'f' for boolean values, needs to be seriously looked into. IMO, this is a bug. I would like to investigate why such values are ending up as strings (and not as booleans or ints), and what is responsible. The responsibility either lies with:
As far as I can see, Drupal is not responsible. The pgsql layer in Drupal is pretty thin, and I don't see how booleans are handled differently in Drupal for pgsql than for mysql. However, I haven't investigated thoroughly. Obviously, if the problem lies with Drupal, then we need to fix it.
If the problem lies with either PHP or with pgSQL, then we should submit bug reports to these projects, and in the meantime, we should modify our pgSQL compatibility layer so as to 'translate' boolean 't' or 'f' strings into booleans or ints, and hence to avoid this bug.
Either way, I really DON'T want to see any more patches that use
CASE WHEN x = 0 THEN 1 ELSE 0 END
SQL. This is a long-winded and annoying way to write SQL, and we shouldn't be forced to write our queries like this. Anyone else who wants to help me in investigating this problem, feel free to help out.Comment #14
havran CreditAttribution: havran commentedHi. I search in PHP bug database and i discover this:
http://bugs.php.net/bug.php?id=29213&edit=1
This is not bug it is feature. For PostgreSQL booleans this seems be only way for compatibility (or we need some additional code in DB layer).
Comment #15
JamieR CreditAttribution: JamieR commentedI ran into this same issue developing my module and used this function whenever I needed to evaluate a bool:
However, since then I've found that MySQL dosen't actually support the BOOL data type, but instead uses TINYINT. So perhaps the bool data type should just never be used... just int?
Comment #16
havran CreditAttribution: havran commentedThis is interesting too:
http://www.computer-books.us/sql_0004.php
There is no simple boolean TRUE/FALSE type in databases - only variant integer or text types, interpreted as boolean :).
Comment #17
(not verified) CreditAttribution: commented