Re: Fixing the btree_gist inet mess - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Fixing the btree_gist inet mess
Date
Msg-id 2774070.1766028398@sss.pgh.pa.us
Whole thread Raw
In response to Re: Fixing the btree_gist inet mess  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
I wrote:
> One potential path forward is to roll up the existing series of
> update scripts to create a new installation-from-scratch script
> btree-gist--1.9.sql which would not try to mark the opclasses as
> default.

> Matthias van de Meent <boekewurm+postgres@gmail.com> writes:
>> Could we either limit this hack to pg_upgrade cases, or add a WARNING
>> whenever this condition is triggered and the DEFAULT flag is
>> overwritten? I think that a user trying to execute such commands
>> should be made aware that some part of their SQL command was ignored.

> I'm not opposed in principle to having a warning, but I don't want one
> to come out when some user merely does CREATE EXTENSION btree_gist.
> And I don't see how to avoid that if we don't touch
> btree-gist--1.2.sql.

Wait a minute ... if we create a rolled-up btree-gist--1.9.sql as
above, and that's the default version, then plain CREATE EXTENSION
wouldn't show the problem anyway.  You'd have to explicitly try to
create an old version to reach the hack.  So maybe a warning-if-
not-in-binary-upgrade-mode wouldn't be too noisy after all.
Let me give that a try.

            regards, tom lane



pgsql-hackers by date:

Previous
From: "cca5507"
Date:
Subject: Re: [PATCH] Add pg_lfind8_nonzero()
Next
From: Amit Kapila
Date:
Subject: Re: DOCS - Clarify the publication 'publish_via_partition_root' default value.