Re: pg_stat_statements and non default search_path

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 not really sure. The only thread I could find on this topic didn't
get any answer:
https://www.postgresql.org/message-id/flat/5E5BB0F8-B05E-47C2-8706-F85E70A6DF7D(at)citusdata(dot)com

> BTW, after thinking about it some more, I don't see how storing the
> search_path would help at all... it's not like you can do anything with
> it unless you have a huge chunk of the parser available.
>

My use case is not really to know the fully qualified name of each
identifier, but being able to optimize a problematic query found with
pg_stat_statements. I can already "unjumble" it automatically, but the
search_path is needed to be able to get an explain or just execute the
query.

Of course, I'd prefer that pgss can generate a fully qualified
normalized query instead of storing the search_path.

> BTW, this issue isn't limited to just tables; it affects almost every
> object identifier you can put in a query, like functions, operators,
> types, etc.

Yes, indeed.

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