> > >>>>> 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), […]
Yes, any driver can use emulated prepared statements: https://github.com/php/php-src/blob/master/ext/pdo/pdo_stmt.c#L483 https://github.com/php/php-src/blob/master/ext/pdo/pdo_stmt.c#L1732 I'm happy to work on the bug fix. I'm leaning towards only applying it to master in case others have coded around this behavior. I maintain pdo_dblib, so I know that driver and its use cases pretty well. But since this would affect more people, I wanted to take people's temperature on the change.
