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
