Date: Mon, 14 Jan 2019 19:04:07 -0500
From: Stephen Frost <sfrost@snowman.net>
To: Andres Freund <andres@anarazel.de>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Simon Riggs <simon@2ndquadrant.com>,
	Robert Haas <robertmhaas@gmail.com>,
	Konstantin Knizhnik <k.knizhnik@postgrespro.ru>,
	Michael Paquier <michael.paquier@gmail.com>,
	Alvaro Herrera <alvherre@alvh.no-ip.org>,
	Christoph Berg <myon@debian.org>,
	Thomas Munro <thomas.munro@enterprisedb.com>,
	Peter Eisentraut <peter.eisentraut@2ndquadrant.com>,
	PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] Surjective functional indexes
Message-ID: <20190115000407.GZ2528@tamriel.snowman.net>
References: 
 <CA+Tgmob_qk-w38Mbp5wCCGH9G8AFpmB0K0aTLujJqHNbBpBNUA@mail.gmail.com>
 <25975.1541618754@sss.pgh.pa.us>
 <20190114223409.3tcvejfhlvbucrv5@alap3.anarazel.de>
 <28044.1547507004@sss.pgh.pa.us>
 <20190114230918.fhp6wktbhg6pjnyw@alap3.anarazel.de>
 <28651.1547507948@sss.pgh.pa.us>
 <20190114234617.GW2528@tamriel.snowman.net>
 <20190114235115.lpapnfcezuoyizo2@alap3.anarazel.de>
 <20190114235518.GX2528@tamriel.snowman.net>
 <20190115000037.zl26h3z43mxi73sr@alap3.anarazel.de>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="/JzuQkpjwuDKEExo"
Content-Disposition: inline
In-Reply-To: <20190115000037.zl26h3z43mxi73sr@alap3.anarazel.de>
User-Agent: Mutt/1.5.24 (2015-08-30)
Precedence: bulk


--/JzuQkpjwuDKEExo
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Greetings,

* Andres Freund (andres@anarazel.de) wrote:
> On 2019-01-14 18:55:18 -0500, Stephen Frost wrote:
> > * Andres Freund (andres@anarazel.de) wrote:
> > > > Or are you suggesting that pg_dump in v12+ would throw errors if it
> > > > finds that set?  Or that we'll dump it, but fail to allow it into a
> > > > v12+ database?  What if v12 sees "recheck_on_update=3D'false'", as =
a v11
> > > > pg_dump might output today?
> > >=20
> > > It'll just error out on restore (including the internal one by
> > > pg_upgrade). I don't see much point in doing more, this isn't a widely
> > > used option by any stretch.
> >=20
> > This.. doesn't actually make sense.  The pg_upgrade will use v12+
> > pg_dump.  You're saying that the v12+ pg_dump will dump out the option,
> > but then the restore will fail to understand it?
>=20
> Why does that not make sense? With one exception the reloptions code in
> pg_dump doesn't have knowledge of individual reloptions. So without
> adding any special case code pg_dump will just continue to dump the
> option. And the server will just refuse to restore it, because it
> doesn't know it anymore.

Ugh, yeah, I was catching up to realize that we'd have to special-case
add this into pg_dump to get it avoided; most things in pg_dump don't
work that way.

As that's the case, then I guess I'm thinking we really should make
pg_upgrade complain if it finds it during the check phase.  I really
don't like having a case like this where the pg_upgrade will fail from
something that we could have detected during the pre-flight check,
that's what it's for, after all.

Thanks,

Stephen

--/JzuQkpjwuDKEExo
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCgAGBQJcPSN2AAoJEO1sijiDR2RVoUYP/0zJeHhORjVhPHGDThGUdkRh
XqKH4ynnqwAVTO90cGkdp0fAxsSPpspu5O0Kht1zDqXDaKWTShKZ+nems8g3ZMPO
1Oif34pP+dpCykee6Ch0H1x00ERj23WIftP68mVqkq1WKlYmQ9GJpC9Ejm/u08wd
MhGXz+yXbEYy3slaiGMWSsHc5g4edb3DDANJo1ycIaVS1eIe0twFUWhhub8kMBte
NFJPubILfiahkp14mpgYJ1JYDyLfdm0hSbuP+/+i9kieYM5nxuyMxrE4smkn7XJI
qywCYRYV/UbcJtsLde0B4J6pJMAB7AE1elK6Rq+fyHDapPg45IgSNxDVyESSY6aA
2yVBdLS3G7dbUMdRJrJ2sG7IviZkvNF1L3JGorx3jTJqZIw38k9TSo1gSA5fbOWM
T6UeERR2Tgo7pOlE5xqyA02ZhyQ3YDb163Bee4R+nD1+QkUc7cRG5Q4npnKCAaZI
4gNpTxlp8g+PACqNVvsS4ZHWVlhSWjLWqy3wyIX5W5RGBplnQZpHOi4Dn7AcpBYl
Fid2UlL6BsAKR8tixVpuVRYm49zruCCPYpcRm2wjAUWhGA6I1xgGEXHmfLgUyEw0
Ps0jpAwTaZYMoUuRDzRXwZAla8TkegE5wpu7A0XsWnuRd/suPotZ0iA4ZtnlYO2j
wMHQKeau6DwEkWsTslEV
=198D
-----END PGP SIGNATURE-----

--/JzuQkpjwuDKEExo--