Re: Fixing the btree_gist inet mess

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Fixing the btree_gist inet mess
Date: 2025-12-18 03:26:38
Message-ID: 2774070.1766028398@sss.pgh.pa.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: 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(at)gmail(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2025-12-18 04:18:01 Re: DOCS - Clarify the publication 'publish_via_partition_root' default value.
Previous Message cca5507 2025-12-18 02:29:00 Re: [PATCH] Add pg_lfind8_nonzero()