When you say this, though: “from the perspective of the PDO user, it *does* make sense to think that a *named* parameter would not need to be bound more than once, no?” … I must disagree a little.

I am not a database guru, so it seems to me that a “:foo” placeholder should be replaced with its respective value everywhere in the statement, not just the first time it shows up. (See the first example I give in the article above.) I think this becomes more-so the case when you get into things like “UNION” queries; why would I bind the same key-value pair more than once, if it’s always the same value for the a particular key?

When it comes to binding *variables*, then I see the argument and agree completely. But for replacement *values*, I don’t so much.

Interesting post, and interesting comments. Hacking on some older (as in 4 months old..) libraries tonight, I got bit by this change after upgrading my laptop to PDO 5.2.1… For me, the change affected code in a save() routine that built an INSERT … VALUES … ON DUPLICATE KEY UPDATE … statement from an array of table fields. Previously, a single named parameter worked fine for both the VALUES clause and the ON DUPLICATE KEY UPDATE clause. Now, I’ll have to hack in a version check and bind the parameters again for PDO >= 5.2.1. Not a huge deal, and I understand the reasoning behind the change. Heck, MySQL certainly has had it’s fair share of such happenings.

However, from the perspective of the PDO user, it *does* make sense to think that a *named* parameter would not need to be bound more than once, no?

Cheers,

Jay

Don’t see a good reason why for bindValue cannot work for multiple placements without memory corruption.

The primary goal is to make life easier for coders and this change does not in my opinion.

I have argued in the past for two different modes for PDO. Once that maximizes portability and specifically disallows features that are not portable. And one that tries to expose as much native functionality as possible. IMHO the long term goal of PDO must be to one day replace the native extensions. This is obviously only possible if we do not artificially limit any of the drivers.

However let me ask my question once more: Why does this apply to bindValue() as well?

Poor phrasing on my part about “supported.” Perhaps “the incorrect behavior was not explicitly disallowed” is more correct? ;-)

I completely agree that the “new” behavior is the right thing to do; security and stability have to be the primary goals.

The bite was not too bad, just unexpected — and even then, nothing that we couldn’t work around. (Having a method in PDO that returns a list of the parsed placeholders, though, would be a wonderful addition; then there’d be no need for the above regex routine, and I’m sure it’d be much faster.)

Finally, my many many thanks for creating and maintaining PDO in the first place; it’s a great piece of work and makes my life a lot easier. :-)

The change was made for two reasons; first and foremost, if you re-use the same variable in a bind, it is possible to induce a crash when using some drivers. It’s not possible to guarantee to do the right thing, and having a way to trigger a crash can sometimes be used as an attack vector for a security exploit.

The second reason is that of portability. Some drivers would internally perform this check and error out. If you code against the drivers that don’t enforce this, then your code won’t work on those that don’t.

I’m sorry that this bit you; it’s hard to notice a change in the handling of “bad” uses if you don’t use it that way.