Re: pg_stat_statements and non default search_path

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

In response to

Responses

Browse pgsql-hackers by date

  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