On 16 Oct. 2016 14:31, "Julien Rouhaud" <julien.rouh...@dalibo.com> wrote: > > On 16/10/2016 02:38, Jim Nasby wrote: > > On 10/10/16 12:58 AM, Julien Rouhaud wrote: > >> Unless you mean deparsing the Query instead of using raw source text? I > >> think that would solve this issue (and also the other issue when > >> multiple queries are submitted at once, you get the normalized version > >> of all the queries multiple time), but AFAIK ruleutils.c doesn't expose > >> enough to do it (like get_query_def()), and exposing it isn't an option. > > > > Why couldn't we expose it?
Advertising
I'm interested in that too, for the purpose of passing the correct substring of a multi-statement to ProcessUtility_hook. Perhaps by using parser position data to generate a start pointer and length within the querystring already passed. For the problem in this thread one could always implement plan-to-query transforms (deparse). But you'd get back something pretty far from the input query after function inlining, subquery flattering, condition pushdown/pullup, join elimination, etc etc. I think pg_stat_plans attempted a middle ground here, capturing explain style plans rather than trying to report the SQL. I do think there is utility to storing search_path and optionally specialising stats according to it. The most obvious case is multi-tenant and schema-sharded models where per-schema stats would be very handy. You'd want to use the active search path though so you eliminate references to nonexistent schemas. Otherwise $user would screw things up.
