Re: Proposal - Enabling btree_gist by default

On Mon, 5 Jan 2026 at 01:41, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> I wrote:
> > Even once that dust settles, I'm not sure that "install the extension
> > by default" is an acceptable approach.
>
> After reflecting a bit, the key problem with that is it'd break
> pg_upgrade of an existing cluster that has the extension installed
> normally. pg_upgrade needs to preserve OIDs of data types and some
> other SQL objects, and there's no way that a pre-installed extension
> would happen to match up with the OIDs the extension used before.
>
> Maybe there's some way we could finesse that, relying on the
> assumption that gbtreekey4 and siblings probably aren't being
> used in user tables so their OIDs wouldn't appear on disk.
> But it seems quite nontrivial to do, even if said assumption
> is safe.
>
> Thanks for the feedback, Tom.

I expect the same complication would exist for anything which
moved functionality including data types into core. Which reinforces the
point for me that extensions and upgrades is the yak that needs to be
shaved before a lot of the discussions about where functionality should be
maintained can be acted on.

I'll strip out the preparatory fix for cleaning up search path settings in
initdb scripts into a separate thread.

FWIW, the discussion which led to proposing enabling the extension by
default had started off as a discussion of what from the contrib extension
world it would be desirable to move into core. Enabling an extension by
default (with PL/pgSQL as an almost-precedent) was seen as a preferable
alternative because:
- It's a less intrusive change (which this thread may have invalidated)
- It keeps the relevant extension points and APIs in use by something
which goes through CI
- By providing that clearer boundary, it may (an admittedly very
speculative may) help to scale the maintenance effort horizontally

Regards
Alastair