On Tue, Oct 22, 2019 at 09:53:45AM -0400, Stephen Frost wrote:
> Yeah.. Something along those lines definitely seems like it'd be better
> as that would force anyone adding new options to explicitly say which
> server version the option makes sense for. Would it make sense to have a
> minimum and a maximum (and a "currently live" or some such indicator, so
> we aren't changing the max every release)?
Yeah. A maximum may help to handle properly the cycling of deprecated
options in connstrs, so I see your point. Not sure that this
"currently-live" indicator is something to care about if we know
already the range of versions supported by a parameter and the
version of the backend for a live connection. My take is that it
would be more consistent to have a PG_MAJORVERSION_NUM for this
purpose in pg_config.h as well (I honestly don't like much the
existing tweaks for the major version numbers like "PG_VERSION_NUM /
100" in pg_basebackup.c & co for example). If we were to have a
maximum, couldn't there also be issues when it comes to link a binary
with a version of libpq which has been compiled with a version of
Postgres older than the version of the binary? For example, imagine a
version of libpq compiled with v11, used to link to a pg_basebackup
from v12.. (@_@)
> The other thought I had was if we should, perhaps, be skipping settings
> whose values haven't been changed from the default value. Currently, we
> end up with a bunch of stuff that, in my experience anyway, just ends up
> being confusing to people, without any particular benefit, like
> 'sslcompression=0' when SSL wasn't used, or 'krbsrvname=postgres' when
> Kerberos/GSSAPI wasn't used...
Couldn't this become a problem if we were to change the default for
some parameters? There has been a lot of talks for example about how
bad sslmode's default it for one, even if nobody has actually pulled
the trigger to change it.
--
Michael