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
|
Список | 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 по дате отправления: