Re: pg_stat_statements and non default search_path

Поиск
Список
Период
Сортировка
От Julien Rouhaud
Тема Re: pg_stat_statements and non default search_path
Дата
Msg-id d63b501c-4c93-a40b-97d3-9bc359edbf91@dalibo.com
обсуждение исходный текст
Ответ на Re: pg_stat_statements and non default search_path  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
Ответы Re: pg_stat_statements and non default search_path  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
Список 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 по дате отправления:

Предыдущее
От: Pavel Stehule
Дата:
Сообщение: Re: proposal: psql \setfileref
Следующее
От: Heikki Linnakangas
Дата:
Сообщение: Re: Logical tape pause/resume