A boolean value is returned as the strings 't' and 'f', not the constants true and false. This presents all kinds of interesting oddities for code that does something like:[...]
You're probably already aware of this, but you can use a bit(1) field as a
boolean and this will map to PHP values that will allow you to check for
truth in conditionals. Personally I do that instead of using Postgres's
boolean since other database systems I've worked with don't have a boolean
type, but they all have a bit type. Although I agree that it would be nice
for PHP to map pg's boolean to PHP's boolean...
*nods* It's a pretty evil behavior, IMHO. It's all too common to have code that essentially does:
$r = pg_query($DB, "select FALSE::BOOL"); $row = pg_fetch_row($r); var_dump($row); if ($row) echo "$row\n"; else echo "not run\n";
Instead all instances of 'if ($row)' have to be converted to something like:
if ($row == 'f')
.. just stayed up all night adding various == '[tf]' snippets to some 100K lines of web goo. *sighs* Moved a large database schema from INTs to BOOLs, and unpleasantly discovered that PHP returns a string that evaluates true, even for false values. Qt did the right thing, but PHP bombed in the worst of ways. :(
This has got to be considered an egregious oversight by the driver authors and is a sharp disconnect from any interpretation of POLS (principle of least surprise).
The same problem lies with the NULL value, which IMHO, should be mapped to the constant NULL, not the string 'NULL'.
I was unable to reproduce this. The following code:
*blush* Yeah, I f-'ed up and misinterpreted the code... this was from PHP's null constant to the generated SQL, not the other way around. The problem with the booleans is still the same, however. I figured there would be only one type map from that would be used when sending/receiving variant data out of the database. -sc
-- Sean Chittenden
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
