From: | Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com> |
---|---|
To: | Julien Rouhaud <julien(dot)rouhaud(at)dalibo(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pg_stat_statements and non default search_path |
Date: | 2016-10-16 00:38:13 |
Message-ID: | b0fb0d8e-ec9c-72f8-f826-607f2bec4988@BlueTreble.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 10/10/16 12:58 AM, Julien Rouhaud wrote:
>> > 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).
Oh, hrm. :/
> 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?
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.
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.
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com
855-TREBLE2 (855-873-2532) mobile: 512-569-9461
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff Janes | 2016-10-16 00:43:40 | Re: process type escape for log_line_prefix |
Previous Message | Serge Rielau | 2016-10-15 17:51:07 | Re: Fast AT ADD COLUMN with DEFAULTs |