Re: StartupMessage parameters - free-form or not?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Jaka Jančar <jaka(at)kubje(dot)org>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: StartupMessage parameters - free-form or not?
Date: 2020-07-12 00:43:31
Message-ID: 2463369.1594514611@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

=?UTF-8?B?SmFrYSBKYW7EjWFy?= <jaka(at)kubje(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2020-07-12 00:47:54 Re: Default setting for enable_hashagg_disk
Previous Message Tomas Vondra 2020-07-12 00:30:37 Re: Default setting for enable_hashagg_disk