Re: pg_stat_statements and non default search_path - Mailing list pgsql-hackers

From Julien Rouhaud
Subject Re: pg_stat_statements and non default search_path
Date
Msg-id cc1f49d0-d674-450d-6f9a-0fa1651877bd@dalibo.com
Whole thread Raw
In response to Re: pg_stat_statements and non default search_path  (Craig Ringer <craig.ringer@2ndquadrant.com>)
List pgsql-hackers
On 16/10/2016 11:21, Craig Ringer wrote:
> On 16 Oct. 2016 14:31, Julien Rouhaud 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?
> 
> I'm interested in that too, for the purpose of passing the correct
> substring of a multi-statement to ProcessUtility_hook.

I have another use case for this: being able to easily print what is the
query (or queries) that are actually executed (ie. what's get out of the
rewriter).  That's useful when trying to figure out / optimize nested
views hell or abuse of rules.

-- 
Julien Rouhaud
http://dalibo.com - http://dalibo.org



pgsql-hackers by date:

Previous
From: Craig Ringer
Date:
Subject: Re: pg_stat_statements and non default search_path
Next
From: Fabien COELHO
Date:
Subject: Re: [PATCH] pgpassfile connection option