Re: Fixing the btree_gist inet mess
Matthias van de Meent <boekewurm+postgres@gmail.com>
From: Matthias van de Meent <boekewurm+postgres@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Heikki Linnakangas <hlinnaka@iki.fi>, pgsql-hackers@lists.postgresql.org
Date: 2025-12-24T21:49:08Z
Lists: pgsql-hackers
On Fri, 19 Dec 2025 at 19:27, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > Here's a v2 patchset that tries to address all the discussion so far. Thanks! > [...] > Because I didn't change DefineOpClass's behavior when > !IsBinaryUpgrade, any attempt to install a pre-1.9 version of > btree_gist will now fail. So we could remove btree_gist--1.2.sql > as well as btree_gist--1.0--1.1.sql and btree_gist--1.1--1.2.sql > without cost. (I've not done that here, as it would just bloat the > patchset some more.) However we should keep btree_gist--1.2--1.3.sql > and later delta scripts, so that users can update old definitions of > the module to 1.9 after a pg_upgrade. That all seems reasonable, yes. > One point perhaps worth mentioning here is that it works to > copy btree_gist--1.8--1.9.sql into a v18 installation and > issue > ALTER EXTENSION btree_gist UPDATE TO '1.9'; > after which pg_upgrade will let you upgrade your old indexes > without complaint, because pg_dump will now do the right things. > I did not document this because (a) it does not work in anything > before v18 due to lack of btree_gist 1.8, and (b) we don't want > to encourage people to stay on the old opclasses in v19. Agreed. > But > perhaps somebody would find a reason to want to do this. Yes, perhaps. I also hope nobody needs to reach for this. > I'd probably squash all this into one commit at the end, but > I made it into several patches for review purposes. LGTM. Kind regards, Matthias van de Meent Databricks (https://www.databricks.com)