Re: pg_stat_statements and non default search_path

From: Julien Rouhaud <julien(dot)rouhaud(at)dalibo(dot)com>
To: Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_stat_statements and non default search_path
Date: 2016-10-10 05:58:34
Message-ID: d63b501c-4c93-a40b-97d3-9bc359edbf91@dalibo.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2016-10-10 06:52:33 Re: Logical tape pause/resume
Previous Message Josh Berkus 2016-10-10 04:51:07 Remove vacuum_defer_cleanup_age