Horton

Re: Fixing the btree_gist inet mess

Tom Lane <tgl@sss.pgh.pa.us>

View thread
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Matthias van de Meent <boekewurm+postgres@gmail.com>
Cc: pgsql-hackers@lists.postgresql.org
Date: 2025-12-18T03:26:38Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Remove now-useless btree_gist--1.2.sql script.

  2. Mark GiST inet_ops as opcdefault, and deal with ensuing fallout.

  3. Create btree_gist v1.9, in which inet/cidr opclasses aren't default.

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