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-f85e70a6d...@citusdata.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
