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 d63b501c-4c93-a40b-97d3-9bc359edbf91@dalibo.com
Whole thread Raw
In response to Re: pg_stat_statements and non default search_path  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
Responses Re: pg_stat_statements and non default search_path  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
List pgsql-hackers
On 10/10/2016 05:00, Jim Nasby wrote:
> On 10/7/16 4:39 AM, Julien Rouhaud wrote:
>> I see two ways of fixing this. First one would be to store normalized
>> queries while fully qualifiying the relation's names. After a quick look
>> this can't be done without storing at least a token location in
>> RangeTblEntry nodes, which sounds like a bad idea.
>>
>> The other way would be to store the value of search_path with each pgss
>> entry (either in shared_memory or in the external file).
>>
>> Is it something that we should fix, and if yes is any of this
>> acceptable, or does someone see another way to solve this problem?
> 
> Would another option be to temporarily set search_path to '' when
> getting the query text? ISTM that would be the best option.

I don't think that possible.  The query text used is raw query text
provided by the post_parse_analyse hook (ParseState->p_sourcetext).

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.

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



pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: proposal: psql \setfileref
Next
From: Heikki Linnakangas
Date:
Subject: Re: Logical tape pause/resume