Thread

Re: Fixing the btree_gist inet mess

Matthias van de Meent <boekewurm+postgres@gmail.com> — 2025-12-11T18:16:18Z

On Fri, 1 Aug 2025 at 20:17, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> There are a couple of loose ends still to be dealt with.  We need
> to say something about this in btree-gist.sgml, but I've not
> attempted to write that text yet.  Also, I expect that
> cross-version-upgrade testing will spit up on the inet/cidr indexes
> created by btree_gist's regression tests.  There's probably
> nothing that can be done about the latter except to teach
> AdjustUpgrade.pm to drop those indexes from the old installation.
>
> 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.

That doesn't remove the need for the pg_upgrade -related code changes,
but I think that just means we need to do both.

As for the rest of the patch:

> +    /*
> +     * HACK: if we're trying to create btree_gist's gist_inet_ops or
> +     * gist_cidr_ops, avoid failure in the next stanza by silently making the
> +     * new opclass non-default.  Without this kluge, we would fail to load
> +     * pre-v19 definitions of contrib/btree_gist.  We can remove it sometime
> +     * in the far future when we don't expect any such definitions to exist.
> +     */
> +    if (isDefault)
> +    {
> +        if (amoid == GIST_AM_OID &&
> +            ((typeoid == INETOID && strcmp(opcname, "gist_inet_ops") == 0) ||
> +             (typeoid == CIDROID && strcmp(opcname, "gist_cidr_ops") == 0)))
> +            isDefault = false;
> +    }

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.


Kind regards,

Matthias van de Meent
Databricks (https://www.databricks.com)