This issue is not difficult to solve in userland, at least well enough for debugging in my experience. Here's an older example I wrote up on my blog that worked (but I'm told is broken right now): https://daveyshafik.com/archives/605-debugging-pdo-prepared-statements.html
Thanks, - Davey On Mon, Dec 5, 2016 at 10:30 AM, Adam Baratz <adambar...@php.net> wrote: > > > > 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 >
