Edit report at https://bugs.php.net/bug.php?id=44597&edit=1
ID: 44597
Updated by: m...@php.net
Reported by: kenaniah at gmail dot com
Summary: [PATCH] Postgres driver does not prepare booleans
correctly
-Status: Open
+Status: Feedback
Type: Bug
Package: PDO related
Operating System: Red Hat 4.1.1
PHP Version: 5.2.6
Block user comment: N
Private report: N
New Comment:
Please try using this snapshot:
http://snaps.php.net/php5.4-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
Seems to work correctly in recent versions.
Previous Comments:
------------------------------------------------------------------------
[2010-10-12 12:20:14] ddebernardy at yahoo dot com
I'm in agreement with the last commenter. The PGSQL driver handles booleans
that
are typecast as integers properly, but not the actual booleans. These really
ought
to work out of the box.
------------------------------------------------------------------------
[2009-10-05 06:08:33] kenaniah at gmail dot com
*Sjoerd
My apologies on the incorrect spelling.
------------------------------------------------------------------------
[2009-10-05 06:07:07] kenaniah at gmail dot com
In response to sjored, I believe there is huge disagreement over that issue,
and I can personally speak for many of my colleagues in saying that. While I
understand the repercussions of the patch, I would also like to point out that
the example cited depends on buggy functionality in the first place. For that
reason alone, I humbly submit that such a case should not be considered when
weighing the implementation of the patch.
On the second point, I believe we have another difference of opinion. All DBMSs
perform their own casting on query parameters to match internal data types. For
example, certain DBs honor the *string* 'False' as a boolean value, whereas a
simple boolean cast performed in PHP would result in the said parameter
evaluating to TRUE. In addition, other transformations may be applied to a
passed parameter based on localization, custom data types, complex data types,
etc. which vary from vendor to vendor and schema to schema. The role of PDO
should be to transparently forward parameters to queries via their respective
PHP and PDO-recognized data types.
Now concerning the third point: PHP is a loosely-typed language. There is
beauty in being able to provide mixed parameters to functions. There is nothing
wrong with allowing a "mixed" parameter to be passed to a query either. Most
DBs operate perfectly fine when receiving mixed parameters, and rightfully
throw an error when something is amiss. Passing 'True', TRUE, or 1 to a boolean
database field is perfectly acceptable in many systems.
And concerning your last statement: PHP should never under any circumstance
attempt to think for the programmer. I expect a database abstraction layer to
pass parameters along transparently *because* it is an abstraction layer. A
programming language is not smarter than the one who implements it, and it is
impossible to mitigate an error in logic. Rather, it is better for an error to
be returned in order so that the erroneous logic be corrected, as their may be
an even greater issue at hand.
In closing, I believe that the implementation of a patch for this issue would
be more inline with the general philosophy and design patterns that govern PHP
than the current functionality today, to the point that I maintain my position
that the current functionality is in fact buggy. I merely ask that PDO -- true
to the form and function of an abstraction layer -- would pass parameters along
in their respective data types without casting them to "string" of all things.
I thank everyone who has participated in this issue thus far (especially sjored
for the patch submitted), and am looking forward to this issue being resolved
in an upcoming release.
------------------------------------------------------------------------
[2009-10-04 18:46:07] sjo...@php.net
It is a bad idea to determine the PDO type from the PHP type.
First, it would break existing scripts which assume false is cast to an empty
string, like this:
$a[] = strstr($foo, $bar); // may return false
$pdo->execute($a);
Secondly, the correct type to use is the type of the column, not the type of
the PHP parameter. Consider the following query:
SELECT * FROM foo WHERE a=?
If a is a boolean, the parameter to execute() or bindBaram() should be
converted to a boolean, no matter what the type of the passed parameter is.
Finally, one of PHP features is that it dynamically changes types. The type of
a variable should be transparent to the user. Therefore, the behavior of a
function should not change when it is passed another type.
To solve this, you should always specify the PDO type. Only the programmer
knows which types the column in the query have, PHP can not determine this
automatically.
------------------------------------------------------------------------
[2009-09-22 18:31:34] sjo...@php.net
Currently, every variable is assumed to be PDO_PARAM_STR. This patch changes
this to PDO_PARAM_INT or PDO_PARAM_BOOL if the passed variable is a long or a
bool, respectively.
http://www.gissen.nl/files/bug44597.patch
This may break existing scripts, which depend on false being converted to an
empty string.
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=44597
--
Edit this bug report at https://bugs.php.net/bug.php?id=44597&edit=1
