From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alexey Klyukin <alexk@hintbits.com>
cc: Alexander Kukushkin <cyberdemn@gmail.com>,
 PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: Report search_path value back to the client.
In-reply-to: 
 <CAAS3tyLsyaAeimsUxAw_RMKY_GnPVN3ntJ9ncr=5E4Q6z1+96g@mail.gmail.com>
References: 
 <CAFh8B=k8s7WrcqhafmYhdN1+E5LVzZi_QaYDq8bKvrGJTAhY2Q@mail.gmail.com>
 <CAAS3tyLsyaAeimsUxAw_RMKY_GnPVN3ntJ9ncr=5E4Q6z1+96g@mail.gmail.com>
Comments: In-reply-to Alexey Klyukin <alexk@hintbits.com>
 message dated "Fri, 20 Feb 2015 10:15:56 +0100"
Date: Fri, 20 Feb 2015 10:19:12 -0500
Message-ID: <20849.1424445552@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

Alexey Klyukin <alexk@hintbits.com> writes:
> On Tue, Dec 2, 2014 at 5:59 PM, Alexander Kukushkin <cyberdemn@gmail.com> wrote:
>> I would like to mark 'search_path' as GUC_REPORT:

> Given this is a one-liner, which doesn't introduce any new code, but
> one flag to the function call, would it be
> possible to review it as a part of the current commitfest?

I'm against this on a couple of different grounds:

1. Performance.  search_path is something that many applications change
quite a lot, so reporting changes in it would create enormous network
overhead.  Consider for example that a SQL function might set it as
part of a function SET clause, and that could be invoked thousands of
times per query.

2. Semantics.  The existing GUC_REPORT variables are all things that
directly relate to client-visible behavior, eg how values of type
timestamp will be interpreted and printed.  search_path is no such thing,
so it's hard to make a principled argument for reporting it that doesn't
lead to the conclusion that you want *everything* reported.  (In
particular, I don't believe at all your argument that this would help
pgbouncer significantly.)

We could possibly alleviate problem #1 by changing the behavior of guc.c
so it doesn't report every single transition of flagged variables, but
only (say) once just before ReadyForQuery if the variable changed in
the just-finished command.  That's not exactly a one-line fix though.

			regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers