Greetings,
* Michael Paquier (michael@paquier.xyz) wrote:
> 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.. (@_@)
Erm, your last concern is exactly why I was saying we'd have a
'currently live' indicator- so that it wouldn't be an issue to have an
older library connecting from a new application to a newer database.
> > 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.
That really depends on if we think that users will expect the
new-default behavior to be used, or the old-default to be. If the user
didn't set anything explicitly when they ran the command in the first
place, then it would seem like they intended and expected the defaults
to be used. Perhaps that's an even better answer- just only put into
the recovery.conf file what the user actually set instead of a bunch of
other stuff...
Thanks,
Stephen