On 04.10.2016 at 16:20, Matteo Beccati wrote: > Hi, > > On 04/10/2016 16:15, Adam Baratz wrote: >>> >>>>> Well, I'm pretty sure Postgres won't be affected either way, because >>> its type system is such that you can't prepare a query where the types of >>> parameters can't be decided yet. A query like this simply gives an error. >>>> >>>> Firebird, oracle and mysql would have exactly the same problem. The >>>> prepare SQL script is invalid so prepare fails. If it works for dblib >>>> then I would consider THAT the bug. Parameters can only be assigned to >>>> fields identified in the prepared SQL. In this case :null has nothing to >>>> identify what it is to be prepared to populate. >>> >>> This is about *emulated* prepares, and AFAIK that means that the >>> database will never see the prepared statement. >> >> >> That's correct, but you can enable emulated prepares for whichever driver. >> A less confusing example might've been inserting :null into a nullable INT >> column and verifying that NULL was stored. > > That's not ture. If memory serves, emulated prepares are only available > supported by the mysql and pgsql pdo drivers.
If that is so, the docs would be in error, e.g. <http://www.php.net/manual/en/pdo.setattribute.php> states: | PDO::ATTR_EMULATE_PREPARES […] | Use this setting to force PDO to either always emulate prepared | statements (if TRUE), […] -- Christoph M. Becker -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
