Re: Report search_path value back to the client. - Mailing list pgsql-hackers

From Alexey Klyukin
Subject Re: Report search_path value back to the client.
Date
Msg-id CAAS3tyLsyaAeimsUxAw_RMKY_GnPVN3ntJ9ncr=5E4Q6z1+96g@mail.gmail.com
Whole thread Raw
In response to Report search_path value back to the client.  (Alexander Kukushkin <cyberdemn@gmail.com>)
Responses Re: Report search_path value back to the client.  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Hi,

On Tue, Dec 2, 2014 at 5:59 PM, Alexander Kukushkin <cyberdemn@gmail.com> wrote:

> It's really crazy to keep so many (hundreds) connections to the database and
> it would be much better to have something like pgbouncer in front of
> postgres.
> Right now it's not possible, because pgbouncer is not aware of search_path
> and it's not really possible to fix pgbouncer, because there is no easy way
> to
> get current value of search_path.
>
> I would like to mark 'search_path' as GUC_REPORT:
> --- a/src/backend/utils/misc/guc.c
> +++ b/src/backend/utils/misc/guc.c
> @@ -2904,7 +2904,7 @@ static struct config_string ConfigureNamesString[] =
>                 {"search_path", PGC_USERSET, CLIENT_CONN_STATEMENT,
>                         gettext_noop("Sets the schema search order for names
> that are not schema-qualified."),
>                         NULL,
> -                       GUC_LIST_INPUT | GUC_LIST_QUOTE
> +                       GUC_LIST_INPUT | GUC_LIST_QUOTE | GUC_REPORT
>                 },
>                 &namespace_search_path,
>                 "\"$user\",public",
>

I know quite a lot of companies using search_path to switch to the
version of sprocs in the database
without changes to the application. Not being able to use pgbouncer in
such scenario is rather annoying.

It would be really great to have this functionality in the upcoming
9.5 and not wait for another year for it.

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?

Kind regards,
-- 
Alexey Klyukin



pgsql-hackers by date:

Previous
From: Kyotaro HORIGUCHI
Date:
Subject: Re: pg_basebackup may fail to send feedbacks.
Next
From: Michael Paquier
Date:
Subject: Re: Expanding the use of FLEXIBLE_ARRAY_MEMBER for declarations like foo[1]