Re: pg_stat_statements and non default search_path

<p dir="ltr"><p dir="ltr">On 16 Oct. 2016 14:31, "Julien Rouhaud" <<a
href="mailto:julien.rouhaud@dalibo.com">julien.rouhaud@dalibo.com</a>>wrote:<br /> ><br /> > On 16/10/2016
02:38,Jim Nasby wrote:<br /> > > On 10/10/16 12:58 AM, Julien Rouhaud wrote:<br /> > >> Unless you mean
deparsingthe Query instead of using raw source text?  I<br /> > >> think that would solve this issue (and also
theother issue when<br /> > >> multiple queries are submitted at once, you get the normalized version<br />
>>> of all the queries multiple time), but AFAIK ruleutils.c doesn't expose<br /> > >> enough to do
it(like get_query_def()), and exposing it isn't an option.<br /> > ><br /> > > Why couldn't we expose it?<p
dir="ltr">I'minterested 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
alreadypassed.<p dir="ltr">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,
conditionpushdown/pullup, join elimination, etc etc.<p dir="ltr">I think pg_stat_plans attempted a middle ground here,
capturingexplain style plans rather than trying to report the SQL.<p dir="ltr">I do think there is utility to storing
search_pathand optionally specialising stats according to it. The most obvious case is multi-tenant and schema-sharded
modelswhere per-schema stats would be very handy. You'd want to use the active search path though so you eliminate
referencesto nonexistent schemas. Otherwise $user would screw things up.