Re: Connection options

On Thu, Jun 15, 2017 at 3:16 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Igor Korot <ikorot01(at)gmail(dot)com> writes:
> > On Thu, Jun 15, 2017 at 4:46 PM, David G. Johnston
> > <david(dot)g(dot)johnston(at)gmail(dot)com> wrote:
> >> The options you pass from the client via the "options" attribute are
> >> interpreted by *the server* as command-line options. They are not
> options
> >> that control libpq itself.
>
> > Can you give an example or try to explain it?
> > What do you mean by "interpreted by the server as command-line options"?
>
> See the switches described in
>
> https://www.postgresql.org/docs/current/static/app-postgres.html
>
> The point of the libpq "options" argument is that you can pass server
> settings using that same switch syntax, for settings you'd be allowed to
> change at runtime. This is obsolete legacy stuff; all of the available
> options can be set with SET commands, and that's the preferred way to do
> it now.
>

​Centralization of client-side logic in self-contained scripts is a thing I
try to do. The recent changes to psql -c/-f in 9.6 seem to now provide me
a viable alternative to passing the desired startup search_path via
options. Prior to 9.6 using a custom PSQLRC and restricting myself to -f
and stdin would get me close; but -c ignoring (without the ability to
override) the PSQLRC sourcing made it imperfect.

I didn't learn that pg_bouncer shared this belief (out of necessity) until
later though. And while I'm inclined to agree I'd suggest we actually make
such a declaration formal so people reading the docs and considering adding
such an argument to their custom psql aliases can instead decide to use
something different. I'm not sure if I'd bleep a deprecation warning from
psql though - if so, adding a silencer switch would be courteous.

David J.