| From: | Andreas Karlsson <andreas(at)proxel(dot)se> |
|---|---|
| To: | Alastair Turner <minion(at)decodable(dot)me>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Proposal - Enabling btree_gist by default |
| Date: | 2026-01-14 01:43:22 |
| Message-ID: | 2277528b-abe5-4772-86bf-042e3a65fbe9@proxel.se |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 1/8/26 11:14 AM, Alastair Turner wrote:
> 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
A not very realistic dream for me would be to move some things (mostly
the money type) out of core rather than moving moe stuff in to core, but
given pg_upgrade and OID stability I do not think that is realistic.
Andreas
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andreas Karlsson | 2026-01-14 01:44:28 | Re: New year, new commitfest app improvements |
| Previous Message | Fujii Masao | 2026-01-14 01:26:36 | Re: pg_recvlogical: Prevent flushed data from being re-sent after restarting replication |