Edit report at http://bugs.php.net/bug.php?id=44597&edit=1
ID: 44597
Comment by: ddebernardy at yahoo dot com
Reported by: kenaniah at gmail dot com
Summary: [PATCH] Postgres driver does not prepare booleans
correctly
Status: Open
Type: Bug
Package: PDO related
Operating System: Red Hat 4.1.1
PHP Version: 5.2.6
Block user comment: N
New Comment:
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.
Previous Comments:
------------------------------------------------------------------------
[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] [email protected]
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] [email protected]
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.
------------------------------------------------------------------------
[2009-09-21 19:48:55] kenaniah at gmail dot com
In response to sjoerd, this may very well be a product of bad
documentation, but that does not exclude the functional use case. One
could reasonably claim that proper detection of parameter types should
in fact be part of the functional definition of execute(). Virtually
every database interface built on top of PDO works around this boolean
"bug" and allows support for mixed content in the parameter array to a
prepared statement.
IMHO, the PDO core should therefore be no different. Whether classified
as a bug or a feature, I believe that this should still be addressed.
------------------------------------------------------------------------
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
http://bugs.php.net/bug.php?id=44597
--
Edit this bug report at http://bugs.php.net/bug.php?id=44597&edit=1
