4 ms·

PDO explicitly does not support the functionality being discussed [1]: > For example, you cannot bind multiple values to a single parameter in the IN() clause

PDO explicitly does not support the functionality being discussed [1]: > For example, you cannot bind multiple values to a single parameter in the IN() clause of an SQL statement. You're required to roll your own implementation, something that thankfully isn't particularly difficult, but unfortunately also seems to be enough of a barrier that a lot of programmers don't bother. [1]: https://www.php.net/manual/en/pdo.prepare.php https://www.php.net/manual/en/pdo.prepare.php

noduerme 5y ago
I'm pretty sure PDO doesn't support escaping WHERE/IN(...) because MySQL prepared statements don't support it. In theory, PDO could support it in emulation mode, but supporting something like that only in emulation would be an antipattern. Similarly, PDO doesn't support dynamic table names. You're expected to roll your own precisely because it demands more situationally specific escaping than regular parameters would, e.g. testing a list of allowed tables.
- yourenotsmart 5y ago
  > would be an antipattern I just want to point out the above is identical to saying "is bad" without explaining why it's bad. We can say it doesn't align with PDO's goal of being barebones library that doesn't add non-native features on top. But that's not what it does. It both omits many native features on the various databases it supports, and has non-native features like hydrating objects, for some reason. I'd say if a PHP library is at the same level as the C library that backs it, that's a failure of design goals. C is intentionally low-level (by modern standards) and PHP is supposed to be high-level and consumable by people with much less clue than C programmers. It's unfortunate that you pretty much need a DBAL (like Doctrine DBAL) on top of a DBAL (PDO) to get some of the missing features. Like, say, escaping identifiers.
  - tored 5y ago
    It is hard to design good API:s that can last for decades. Just look at Java, language that is backed by large international corporations but the Java standard library still sucks. PHP core is a much smaller community driven project. Key to great APIs is battle tested APIs in real world projects, finetuned over years of experience. PHP has that in the much larger general PHP community and to access it you use composer. We, the PHP community, must use all resources to compete with other languages, it is unrealistic that the core PHP team can implement a great API, for example we can look at the filter API, it works but it is not great. PHP core also has longer release cycles. We need to push PHP developers to use composer more, maybe the PHP docs should state that.
TrispusAttucks 5y ago
To be fair prepared statements happen at the RDBMS. PDO is just a library to interface with that. It can't compile a query execution plan without knowing the table and columns involved. So dynamic tables or columns as variables doesn't make sense so you need to handle that outside the prepared statement as it doesn't belong there.
- noduerme 5y ago
  Just out of curiosity, do you have a preferred mysql library in nodejs? I wrote my own based on node-mysql that does server-side prepared statements, but it does them by compiling PREPARE and SET calls, not through a lower-level language. It works for my needs, but it's not really high-performance.

noduerme 5y ago

I'm pretty sure PDO doesn't support escaping WHERE/IN(...) because MySQL prepared statements don't support it. In theory, PDO could support it in emulation mode, but supporting something like that only in emulation would be an antipattern. Similarly, PDO doesn't support dynamic table names. You're expected to roll your own precisely because it demands more situationally specific escaping than regular parameters would, e.g. testing a list of allowed tables.

yourenotsmart 5y ago
> would be an antipattern I just want to point out the above is identical to saying "is bad" without explaining why it's bad. We can say it doesn't align with PDO's goal of being barebones library that doesn't add non-native features on top. But that's not what it does. It both omits many native features on the various databases it supports, and has non-native features like hydrating objects, for some reason. I'd say if a PHP library is at the same level as the C library that backs it, that's a failure of design goals. C is intentionally low-level (by modern standards) and PHP is supposed to be high-level and consumable by people with much less clue than C programmers. It's unfortunate that you pretty much need a DBAL (like Doctrine DBAL) on top of a DBAL (PDO) to get some of the missing features. Like, say, escaping identifiers.
- tored 5y ago
  It is hard to design good API:s that can last for decades. Just look at Java, language that is backed by large international corporations but the Java standard library still sucks. PHP core is a much smaller community driven project. Key to great APIs is battle tested APIs in real world projects, finetuned over years of experience. PHP has that in the much larger general PHP community and to access it you use composer. We, the PHP community, must use all resources to compete with other languages, it is unrealistic that the core PHP team can implement a great API, for example we can look at the filter API, it works but it is not great. PHP core also has longer release cycles. We need to push PHP developers to use composer more, maybe the PHP docs should state that.

TrispusAttucks 5y ago

To be fair prepared statements happen at the RDBMS. PDO is just a library to interface with that. It can't compile a query execution plan without knowing the table and columns involved. So dynamic tables or columns as variables doesn't make sense so you need to handle that outside the prepared statement as it doesn't belong there.

noduerme 5y ago
Just out of curiosity, do you have a preferred mysql library in nodejs? I wrote my own based on node-mysql that does server-side prepared statements, but it does them by compiling PREPARE and SET calls, not through a lower-level language. It works for my needs, but it's not really high-performance.