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

 ID:                 40417
 Comment by:         spam at shishnet dot org
 Reported by:        exaton at free dot fr
 Summary:            Suddenly binding as many vars as there are
                     *identical* prepared tokens
 Status:             Closed
 Type:               Bug
 Package:            PDO related
 Operating System:   Windows XP Pro SP2
 PHP Version:        5.2.1
 Block user comment: N
 Private report:     N

 New Comment:

Can someone clarify what is meant by "fixed"? I'm finding that binding multiple 
paramaters with the same name works fine for PDO/mysql, but fails in weird ways 
for PDO/postgres...


Previous Comments:
------------------------------------------------------------------------
[2007-03-06 00:53:01] il...@php.net

This bug has been fixed in CVS.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.



------------------------------------------------------------------------
[2007-03-03 15:13:15] exaton at free dot fr

*Damn* *it*.

Good on you for spotting that, mgagne. For some freaking reason I was so bent 
on examining the documentation for binding methods that I skipped prepare(). No 
idea why.

Ilia, my apologies again, therefore ; but really I had not understood your 
intermediate reply. At least now we have the knowledge that you were working 
with all along.

So now, of course, the question is : should the spec' be changed in favor of 
PHP's behaviour up until now ? I of course advocate changing the manual, 
allowing for the new "feature" of multiple parameter markers with the same 
name. I argue with the following points :

1) This issue already seems quite popular ; obviously, quite a few people 
relied on the feature without realizing that it went against the true 
specification.

Now that, of course, is a rather specious argument ; developers working with 
PHP should stick to the spec' and get bent if they make use of unintended 
functionality which is suddenly dropped -- I'm the first to agree. However :

2) I see no compelling reason for which PHP should not "support" this feature. 
It is a very natural feature that makes perfect sense when it is used. It is 
most practical is naive search engine implementations for small sites 
(auto-generated : WHERE (title LIKE :term0 OR text LIKE :term0 OR author_name 
LIKE :term0) AND (title LIKE :term1 OR text LIKE :term1 OR author_name LIME 
:term1) ...).

The underlying code is already designed in such a way as to support the feature 
of multiple parameter markers with the same name. The only change in PHP 5.2.1 
is a condition check that throws an error, based on the specification. And 
admittedly, writing that check in conformance with the "feature" would be 
expensive (see e.g. my suggestion above) and/or cumbersome or complicated, etc.

This would be a call for the PHP core developers.

------------------------------------------------------------------------
[2007-03-02 21:59:15] mgagne at generationphp dot net

Unfortunately for some people, Iliaa is right:

"You cannot use a named parameter marker of the same name twice in a prepared 
statement."

However, even if it's was added to the documentation about a year ago (Sun Jan 
8 14:02:42 2006 UTC), the behavior changed between PHP 5.2.0 and PHP 5.2.1 and 
it should have been added to the changelog as well.

I didn't know when happened to my application until I saw this bug report.

------------------------------------------------------------------------
[2007-03-02 07:25:23] mgagne at generationphp dot net

Hi,

I have the same bug using PHP 5.2.1. I had to downgrade to PHP 5.2.0 and it 
fixed the problem.

I'm using PDO::MYSQL. I have 2 bound variables in my request. All 2 have the 
same name. Since I'm only binding value once using PDO::bindValue, the error is 
triggered without valid reason.

My query is similar to this one:

SELECT *
FROM posts
WHERE post_title LIKE :q OR
      post_text LIKE :q

I'm binding value once like this:

$sth->bindValue(':q', "$q", PDO::PARAM_STR);

This means there is something wrong within the internal count.

Also for the records, issue does not seem to be related to any specific PDO 
driver. (issue is present with PostGreSQL and MySQL driver)

Thanks

------------------------------------------------------------------------
[2007-03-01 15:30:09] exaton at free dot fr

@ xing : I had not seen that word from Wez, but indeed is does make sense to 
add the check in principle -- the API should make sure that enough tokens were 
bound (to enhance its service and avoid "silent" bugs) and can also guarantee 
that not too many were bound (might as well).

It's back to the problem with bindno, however... I'm not even sure of the name 
of that variable. I think it would stand for "number of bindings", e.g. the 
expected number of bound variables or values. I believe that's how Ilia read 
it, and quite reasonably so. That meaning is just not valid in the special (but 
probably not uncommon) case of multiple named tokens (as opposed to question 
marks ?) with the same name.

Just a shot in the dark : wouldn't a workable, albeit expensive, solution be to 
create a little hash table here with the names of all the named tokens ? It 
would not hold duplicates, by definition ; hence named tokens with the same 
name would only be counted once. Therefore zend_hash_num_elements(params) would 
just have to be compared to zend_hash_num_elements(token_names). But of course 
question-mark placeholders would have to be treated in a different way...

Anyway, I don't think that's anything the PHP developers won't have thought 
about themselves. Just my 2 cents.

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


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


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

Reply via email to