From: Tom Lane <tgl@sss.pgh.pa.us>
To: Stephen Frost <sfrost@snowman.net>
cc: Andres Freund <andres@anarazel.de>, 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
In-reply-to: <20190114234617.GW2528@tamriel.snowman.net>
References: <20180511033227.vvgm3yi5xngro2hp@alap3.anarazel.de>
 <CANP8+jKD+u-oW-whEdx1+k_NjAwHU4PvNse-qLp-o_d2zSXW7A@mail.gmail.com>
 <20180511143737.rvogcsxdksrhyyj5@alap3.anarazel.de>
 <CANP8+jLgdS-_ka5bhyG_=f5wGYVY-bQy3YD7rJY=TDnpA1snmg@mail.gmail.com>
 <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>
Comments: In-reply-to Stephen Frost <sfrost@snowman.net>
	message dated "Mon, 14 Jan 2019 18:46:18 -0500"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <30006.1547509982.1@sss.pgh.pa.us>
Date: Mon, 14 Jan 2019 18:53:02 -0500
Message-ID: <30007.1547509982@sss.pgh.pa.us>
Precedence: bulk

Stephen Frost <sfrost@snowman.net> writes:
> * Tom Lane (tgl@sss.pgh.pa.us) wrote:
>> After a few minutes' more thought, I think that the most attractive
>> option is to leave v11 alone and do a full revert in HEAD.  In this
>> way, if anyone's attached "recheck_on_update" options to their indexes,
>> it'll continue to work^H^H^H^Hdo nothing in v11, though they won't be
>> able to migrate to v12 till they remove the options.  That way we
>> aren't bound to the questionable design and naming of that storage
>> option if/when we try this again.

> So the plan is to add a check into pg_upgrade to complain if it comes
> across any cases where recheck_on_update is set during its pre-flight
> checks..?

It wasn't my plan particularly.  I think the number of databases with
that option set is probably negligible, not least because it was
on-by-default during its short lifespan.  So there really has never been
a point where someone would have had a reason to turn it on explicitly.

Now if somebody else is excited enough to add such logic to pg_upgrade,
I wouldn't stand in their way.  But I suspect just doing the revert is
already going to be painful enough :-(

> What if v12 sees "recheck_on_update='false'", as a v11
> pg_dump might output today?

It'll complain that that's an unknown option.

			regards, tom lane