Alexey Klyukin <al...@hintbits.com> writes:
> On Tue, Dec 2, 2014 at 5:59 PM, Alexander Kukushkin <cyberd...@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
