Re: pg_stat_statements and non default search_path - Mailing list pgsql-hackers

From Jim Nasby
Subject Re: pg_stat_statements and non default search_path
Date
Msg-id b0fb0d8e-ec9c-72f8-f826-607f2bec4988@BlueTreble.com
Whole thread Raw
In response to Re: pg_stat_statements and non default search_path  (Julien Rouhaud <julien.rouhaud@dalibo.com>)
Responses Re: pg_stat_statements and non default search_path  (Julien Rouhaud <julien.rouhaud@dalibo.com>)
List 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



pgsql-hackers by date:

Previous
From: Serge Rielau
Date:
Subject: Re: Fast AT ADD COLUMN with DEFAULTs
Next
From: Jeff Janes
Date:
Subject: Re: process type escape for log_line_prefix