Excellent, thanks! On Sat, Jul 11, 2020 at 8:43 PM Tom Lane <t...@sss.pgh.pa.us> wrote:
> =?UTF-8?B?SmFrYSBKYW7EjWFy?= <j...@kubje.org> writes: > > I wrote a Postgres client and in it I allow the user to specify arbitrary > > StartupMessage parameters (Map<string,string>). This is convenient > because > > the user can for example set search_path without issuing a separate SET > > query or encoding things into the "options" parameter. The protocol > > documentation also says that the latter is deprecated and what I'm doing > > (if I understand it right) is preferred. > > Sure. > > > A fellow author of a driver for a different language reminds me that > libpq > > explicitly enumerates the supported parameters in the docs, and I checked > > the code, and indeed there is a whitelist and others are rejected. > > Not sure what you're looking at, but the issue for libpq is that the set > of "options" that it accepts in connection strings is independent of the > set of backend GUC names (and relatively few of them actually correspond > directly to backend GUCs, either). I suppose we could make it pass > through unrecognized options, but that would be an unmaintainable mess, > because both sets of names are constantly evolving. > > It's a bit of a hack that the backend accepts GUC names directly in > startup messages, but the set of "fixed" parameter names in that context > is very short and has barely changed in decades, so we haven't had > conflict problems. > > > technically, he's correct: it's nowhere documented that sending e.g. > > search_path in StartupMessage parameters will work, and for that matter > > whether everything that you can set using SET you can also send there. > > protocol.sgml saith (under Message Formats) > > In addition to the above, other parameters may be listed. Parameter > names beginning with _pq_. are reserved for use as protocol > extensions, while others are treated as run-time parameters to be set > at backend start time. Such settings will be applied during backend > start (after parsing the command-line arguments if any) and will act > as session defaults. > > Admittedly, that doesn't directly define what it means by "run-time > parameter", but what it means is any settable GUC. > > regards, tom lane >
