ID:               40417
 Comment by:       xing at mac dot com
 Reported By:      exaton at free dot fr
 Status:           Open
 Bug Type:         PDO related
 Operating System: Windows XP Pro SP2
 PHP Version:      5.2.1
 New Comment:

I have to agree with exaton on this. This is an absolute "app-breaker"
change and MUST be noted in the change-log at the very least.

It is pure luck I found this change before my official upgrade to
5.2.1.

I really hope there there a solution to this.

On a blog, wez mentioned that this was a fix and the previous ability
to bind one to many placements was rather an bug. I however, strongly
disagree on a simple level that the pre-5.2.1 pdo binding just "made
sense". Why should php force developers to introduce more lines of code
that does nothing more when this can be take care of behind the scenes?


Previous Comments:
------------------------------------------------------------------------

[2007-02-27 13:00:47] exaton at free dot fr

Hi again, thanks for reopening this issue.

Sorry for being so snarky before, but I'd just received a little
dressing down from my boss because of having to add the workaround to
already-validated code at extremely short notice. Classic case of
pushing for an upgrade on the production server in the frenzy of the
moment.

I'll let you guys take care of this now. I've kept my test case around
so I'm available for further trials if I can be of any use.

------------------------------------------------------------------------

[2007-02-27 11:50:41] [EMAIL PROTECTED]

This is really annoying issue, which forces me to rewrite some 
of the code I've done in the past. Perhaps the bindno 
shouldn't be incremented if the named placeholder already 
exists in the placeholders struct? Would it break something 
else?

------------------------------------------------------------------------

[2007-02-24 08:47:52] exaton at free dot fr

Wow. I'm flabbergasted.

Mr Alshanetsky, I am, as they say, and until further notice,
disappointed in you.

No update of the CVS code. Not even a note in the manual to reflect
this spec change.

I guess this is going to have to wait until someone else reports it.
It's got to be relatively common, especially in not too complex search
engine implementations.

Until then, therefore...

------------------------------------------------------------------------

[2007-02-24 03:19:49] [EMAIL PROTECTED]

Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php

.

------------------------------------------------------------------------

[2007-02-16 11:26:30] exaton at free dot fr

Hey again people,

I don't mean to be annoying, but I've just done a bit more research, so
I thought I'd share it with you.

Iliaa, I found the code change where you added the infamous
spec-altering error check that I'm going on about :

PHP_5_2 :
http://cvs.php.net/viewcvs.cgi/php-src/ext/pdo/pdo_sql_parser.c?r1=1.35.2.6.2.3&r2=1.35.2.6.2.4

Also applied to MAIN, with both times the comment : "Added missing
check for mismatching number of tokens & bound params in prepared
statement emulation."

That perfectly matches my error conditions.

The problem is, the bindno variable contains the number of individual
tokens. However, multiple tokens may have the same name ; but each
token name can only be bound once ! So comparing bindno to the number
of bindings is incorrect. It introduces the following specification :
"multiple tokens may not have the same name in a prepared statement".

The workaround is still the same : binding enough bogus tokens to match
the number of individual tokens used in the prepared statement, when
some share the same name.

Oh, did I mention that this prevented anyone with prepared statements
containing multiple tokens sharing the same name from upgrading to PHP
5.2.1 ? :-)

------------------------------------------------------------------------

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/40417

-- 
Edit this bug report at http://bugs.php.net/?id=40417&edit=1

Reply via email to