On Thu, Jun 15, 2017 at 3:16 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Igor Korot <ikorot01@gmail.com> writes: > On Thu, Jun 15, 2017 at 4:46 PM, David G. Johnston > <david.g.johnston@gmail.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"?
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.
