[RFC] Debugging PDO Prepared Statement Emulation v2

Hi,

Basically, you'd never see this kind of example:

SQL: "SELECT * FROM tbl WHERE x = ?"

Sent SQL: "SELECT * FROM tbl WHERE x = $1"

why not? That's what active_query_string contains e.g. in pdo_pgsql w/o
emulate prepares. Which is more or less what has been sent to the
server, unless cursors are used. I don't see why it is deemed to be
not-useful or less useful than emulated prepares.

active_query_string is only set with emulated prepares. I tried my patch
with pdo_pgsql. "Sent SQL" doesn't appear with real prepares. I put it up
here, with tests, if it'll help try it out:
https://github.com/adambaratz/php-src/commit/a030d2f4e6a13f3e6c10484fb5dbc4e8be6576c6

I'll incorporate it, and the content of this subthread, in the RFC when I
get my next free five minutes. :)

In fact it would come in very handy for extended tests of a bugfix I

have in the pipeline.

I'm not sure how to get the query with the $1. My understanding of
pdo_pgsql/pgsql_stmt_execute() is that it creates some PG-specific data
structures for prepared statements. Since they're attached to
a pdo_pgsql_stmt value, you'd have to write some driver-specific code to
get them out.

Maybe there's a simple way to do what you're describing, but my instinct is
that it would be better to keep it out-of-scope for this RFC.

Thanks,
Adam

Hi,

Could you please explain what's the use case? As far as I'm concerned
such information would only be useful during PDO driver development,
phpt files and bug reporting / fixing.

Sometimes I'd like to log what SQL is really used that I can
analyze/modify a query without the need to replace all bound parameters
manually before applying it to the command line of my database.

Additionally, it's a matter of good style in my opinion. E.g. if you
return an array you can extend the structure later. If some test checks
a string output you have to change this. If it checks the values of some
array keys, the test is stable as long as you just add new keys.

Your planned usage only applies if you use emulated prepared statements,
so it's not really something one should depend on.

That said, alas the only debug facility in PDO prints directly to
output. Version 1 of this RFC added something completely different and
v2 fixes it re-using what PDO already has.

If you ask me, what PDO offers sucks, but that's what we've got and
improving it is out of scope for this RFC. Anyone could create a new RFC
to add array output to debugDumpParams, that would be most welcome.

Cheers

Matteo Beccati

Development & Consulting - http://www.beccati.com/

Could you please explain what's the use case? As far as I'm concerned

such information would only be useful during PDO driver development,
phpt files and bug reporting / fixing.

It's pretty simple : debugging and optimizing scripts and statements. I've
lost hours, manually emulating tons of statements, or trying to guess
what's happening when I have something like 1000+ prepared values (mass
insert). And since I have to do it by hand, mistakes happen, so I lose even
more time debugging my emulations. Having a direct access to the emulated
statements, without having to dirtily parse a dump, will be a huge plus for
me, my team and the performances of my debug component.

I understand the use case -- I submitted the "v1" RFC, after all -- but the
discussion for the last RFC seemed to stall at an "agree to disagree"
stage. My hope with "v2" is that it'll be favored more than the first one,
which basically squeezed past the required margin for acceptance.

That said, do you have thoughts on a third approach? It might be that we
should do what Matteo suggested earlier in this thread: make something more
robust for getting structured data out of statements. To be honest, the v2
RFC does exactly what I need. It'll let me write .phpt tests and do one-off
debugging.

But if your take is that simply that you prefer v1 over v2, the regular
vote should cover that.

Thanks,
Adam