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.
http://dalibo.com - http://dalibo.org
Sent via pgsql-hackers mailing list (email@example.com)
To make changes to your subscription: