Heikki Linnakangas <[email protected]> writes:
> On 01/08/2025 21:17, Tom Lane wrote:
>> It's past time to move this problem along and try to get out of the
>> business of encouraging use of known-broken code. I propose that
>> for v19, we should flip the opcdefault status so that network_ops is
>> marked default and the btree_gist opclasses are not. This will be
>> enough to ensure that network_ops is used unless the user explicitly
>> specifies to do differently.
> I wonder if we could move the old opclass's code to core, and somehow
> detect at runtime e.g. by looking at the root page, whether the index
> was built before the upgrade. Hack initGISTstate() to redirect
> everything to the old AM if it was created before the upgrade. The idea
> is that after upgrade, all indexes would appear to be using the new
> opclass if you look at the catalogs, but if it was pg_upgraded from an
> older version, it would actually use the old functions. If you REINDEX,
> it would get recreated in the new format, and would start using the new
> functions. That would be the best user experience, but not sure it's
> worth the effort and all the special hacks.
It's more work than I want to do, anyway. Also, that path would
pretty much mean we could never get rid of the broken code.
> Instead of having the hack in DefineOpClass(), we could have a similar
> hack in pg_dump's dump_opclass(), only in binary upgrade mode.
Hmm ... I'll take a look at that. However, that would not allow
people to install pre-1.9 versions of btree_gist, at least not without
manually editing the extension script.
> Putting all that together, you get a more aggressive plan:
> - Remove the old opclass entirely
> - Remove all old btree_gist--*.sql scripts, start afresh with
> btree_gist--1.9.sql
> - Hack pg_dump, in binary upgrade mode, to dump the btree_gist extension
> as simply "CREATE EXTENSION btree_gist;", instead of dumping the
> individual members like it usually does.
I think that that is where we want to end up in a release or two.
But as I explained upthread, I'm afraid to do it right off the bat:
I don't have 100% confidence in the new opclass code because I fear
it hasn't gotten enough road mileage. So I don't want to tell people
they flat out cannot use the old code as of v19. I think switching
the default choice of opclass is the right amount of risk for v19.
We could plan to remove the old code as of v20 or v21 or so.
regards, tom lane
