At Tue, 20 Dec 2016 22:42:48 -0500, Robert Haas <robertmh...@gmail.com> wrote in <CA+TgmoZT94brLAGK7gCmxB4mO=C-Cdz1N8KN8Xen4sexHozN=q...@mail.gmail.com> > On Tue, Dec 20, 2016 at 6:18 AM, Fabien COELHO <coe...@cri.ensmp.fr> wrote: > > Would this approach be acceptable, or is modifying Nodes a no-go area? > > > > If it is acceptable, I can probably put together a patch and submit it. > > > > If not, I suggest to update the documentation to tell that > > pg_stat_statements does not work properly with combined queries. > > I think you've found a bug, but I'm a little doubtful about your > proposed fix. However, I haven't studied the code, so I don't know > what other approach might be better.
That will work and doable, but the more fundamental issue here seems to be that post_parse_analyze_hook or other similar hooks are called with a Query incosistent with query_debug_string. It is very conveniently used but the name seems to me to be suggesting that such usage is out of purpose. I'm not sure, though. A similar behavior is shown in error messages but this harms far less than the case of pg_stat_statements. ERROR: column "b" does not exist LINE 1: ...elect * from t where a = 1; select * from t where b = 2; com... ^ 1. Let all of the parse node have location in debug_query_string. (The original proposal) 2. Let the parser return once for each statement (like psql parser) and corresponding query string is stored in a varialble other than debug_query_string. ... regards, -- Kyotaro Horiguchi NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers