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:

> 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

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

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to