I really doubt this method will prove useful in practice for the use case you mention, and for a number of a reasons.
1) The name is misleading (there is no real query string in the case of native prepared statements - the SQL and data are always separate) 2) You would have to execute the statement first in order to get the debug information you're looking for (meaning that if the execution of the statement fails for any reason other than what the SQL parser can detect, there is no useful debug information from this method) 3) This only works if you use emulated prepares, which creates a whole new stream of complaints by people who don't understand the difference I don't think the real problem is seeing the entire query assembled with the parameters filled in, because the buggy part would never be the actual parameter values themselves. If there is a bug in the SQL, it's typically the result of a syntax error, or constraint violation, or name error. I sincerely doubt this method would prove useful in debugging in any of those things. The server-side error messages from the DBMS would prove more useful in those cases. In other words, I believe people would get more useful debug information by just turning off emulated prepares, putting PDO into Exception error mode, and looking at the error information provided by the DBMS since with server-side prepares you get failure upon preparing, and before execution even begins, such that parameters are no longer the actual concern for error. On Thu, Oct 13, 2016 at 2:42 PM, Matteo Beccati <p...@beccati.com> wrote: > Hi, > > On 13/10/2016 19:59, Adam Baratz wrote: > > I'd like to add a new method that would return the prepared statement as > it > > was executed. It's common for people I work with to want this info for > > debugging, but you can't get it from userland. The functionality is > similar > > to, but distinct from PDOStatement::debugDumpParams(). > > > > I figure it's always easier to discuss proposals alongside real code: > > https://github.com/php/php-src/pull/2159 > > > > Please let me know what you think, if an RFC would be appropriate, or > what. > > To be perfectly honest, my wish is that EMULATE_PREPARES could be > deprecated and removed and I see something this as a step in the > opposite direction. > > That said, I think a tiny RFC that explains what's the problem you are > trying to solve, the current issue and possible other solutions would be > very welcome. This is an API change and most likely will require all the > drivers to be adapted. > > > Cheers > -- > Matteo Beccati > > Development & Consulting - http://www.beccati.com/ > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
