Re: Report search_path value back to the client.

Alexey Klyukin <alexk(at)hintbits(dot)com> writes:
> On Tue, Dec 2, 2014 at 5:59 PM, Alexander Kukushkin <cyberdemn(at)gmail(dot)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