From: Stephen Frost <sfrost@snowman.net>
To: Andres Freund <andres@anarazel.de>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Simon Riggs <simon@2ndquadrant.com>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: Konstantin Knizhnik <k.knizhnik@postgrespro.ru>
Cc: Michael Paquier <michael.paquier@gmail.com>
Cc: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: Christoph Berg <myon@debian.org>
Cc: Thomas Munro <thomas.munro@enterprisedb.com>
Cc: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Cc: PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] Surjective functional indexes
Date: Mon, 14 Jan 2019 19:04:07 -0500
Message-ID: <20190115000407.GZ2528@tamriel.snowman.net> (raw)
In-Reply-To: <20190115000037.zl26h3z43mxi73sr@alap3.anarazel.de>
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>
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='false'", as a v11
> > > > pg_dump might output today?
> > >
> > > 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.
> >
> > 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?
>
> 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
Attachments:
signature.asc (application/pgp-signature, 818B) download
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: sfrost@snowman.net, andres@anarazel.de, tgl@sss.pgh.pa.us, simon@2ndquadrant.com, robertmhaas@gmail.com, k.knizhnik@postgrespro.ru, michael.paquier@gmail.com, alvherre@alvh.no-ip.org, myon@debian.org, thomas.munro@enterprisedb.com, peter.eisentraut@2ndquadrant.com
Subject: Re: [HACKERS] Surjective functional indexes
In-Reply-To: <20190115000407.GZ2528@tamriel.snowman.net>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox