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
signature.asc
Description: PGP signature
