Re: how to gate experimental features (SQL/PGQ)

From: Kai Wagner <kai(dot)wagner(at)percona(dot)com>
To: Peter Eisentraut <peter(at)eisentraut(dot)org>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>
Subject: Re: how to gate experimental features (SQL/PGQ)
Date: 2026-01-14 18:53:15
Message-ID: CAG0qCNiyT1B5BTvZGoeagK4wAC3kcsy+d1eNSVwZ5E-VE11ueA@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Jan 13, 2026 at 3:18 PM Peter Eisentraut <peter(at)eisentraut(dot)org> wrote:
>
*snip*
> Also, perhaps others have had similar thoughts about other development
> projects, in which case it would be good to get an overview and think
> about how these principles could be applied in a general way.
>

I'm not getting tired of adding TDE to this list, as one way or
another, this will require either extensibility changes in a minimal
case or more, depending on the route we take in the future.

> Just to put forward another example that I'm familiar with, I have this
> currently-dormant column encryption patch set [1] that has vaguely
> similar properties in that it is a large patch, lots of boilerplate,
> lots of details that are best checked while actually using it, but
> possibly requiring incompatible changes if fixes are required.

From an end-user perspective, option 2 appears to be the most sensible
and feasible choice. You're absolutely right; some things do need user
testing and feedback before it's known if and how they might be
finally useful, or what additional adjustments are needed. The
question is how to select these experimental features based on which
specific criteria. At the same time, I understand Andres' concern
about being too big, and smaller increments are the way to go, as
there isn't a single person capable of reviewing everything. The
biggest strength is the maturity and sometimes the slow pace of
PostgreSQL, so the question would be how to define the acceptance, so
it doesn't end up being "spoiled".

For the actual timing, this should occur as part of the major release.
We should definitely avoid incorporating experimental features into
minor updates, as this contradicts the overall stability and concept
of the current major updates.
>
> [1]:
> https://url.avanan.click/v2/r01/___https://www.postgresql.org/message-id/flat/89157929-c2b6-817b-6025-8e4b2d89d88f*40enterprisedb.com___.YXAzOnBlcmNvbmE6YTpnOjg2M2Y3NTQxYWY1YjFhZjBmOTcyMDA2NTI0M2UyM2QzOjc6N2EwYjoyMzY5ZWRiNTdkNDRjYTM0ZWFmZWNjNDM0YTk0M2Y3MTY4NzlhMGJmNTZjNDMzY2U0MWJhOTc4NDIwZTI3YzljOnA6VDpO
>
>
>
>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Masahiko Sawada 2026-01-14 18:56:18 Re: Refactor replication origin state reset helpers
Previous Message Bertrand Drouvot 2026-01-14 18:52:28 Re: code contributions for 2025, WIP version