Matthias van de Meent <[email protected]> writes:
> On Fri, 1 Aug 2025 at 20:17, Tom Lane <[email protected]> wrote:
>> Thoughts?
> This was long overdue from a project perspective, so thanks for picking this
> up.
> I think we should still adjust btree-gist--1.2.sql, if only because it
> adds stronger protections against any future installs that might try
> to get this flag configured. Especially if we at some point in the far
> future want to be able to remove this hack we should stop shipping
> code that would break without the hack in new releases.
Well ... mumble. Project policy has been that extension scripts don't
change once shipped. We have no experience with violating that policy
and hence little certainty about what might break. I don't think that
we can be certain that nothing will break, because for example there
might be some packager out there who has relied on that policy and
decided they could store extension scripts from multiple PG releases
in one directory.
It's probably worth crossing that bridge at some point, but I'd
rather not make a bug fix dependent on it.
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. And I guess we could provide a btree-gist--1.8--1.9.sql
update script that includes manual catalog updates to turn off the
opcdefault flags if they're somehow on; though I'm not sure that
that case would be reachable, so maybe the 1.8--1.9 update could
as well be empty. Sometime in the very far future, when we have
deprecated pg_upgrade from pre-v19 versions, we could remove all
the pre-1.9 script versions and remove the hack in DefineOpClass.
BTW, one reason why I'm not *that* excited about this is that we've
tolerated some related hacks for a very long time indeed. See for
instance this twenty-year-old gem in DefineIndex:
/*
* Hack to provide more-or-less-transparent updating of old RTREE
* indexes to GiST: if RTREE is requested and not found, use GIST.
*/
if (strcmp(accessMethodName, "rtree") == 0)
{
ereport(NOTICE,
(errmsg("substituting access method \"gist\" for obsolete
method \"rtree\"")));
accessMethodName = "gist";
tuple = SearchSysCache1(AMNAME, PointerGetDatum(accessMethodName));
}
> 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. In practice, the odds that somebody would hit
this behavior in some other context seem negligible: nobody would be
re-using btree_gist's opclass names.
regards, tom lane
