| From: | Matheus Alcantara <matheusssilv97(at)gmail(dot)com> |
|---|---|
| To: | Daniel Gustafsson <daniel(at)yesql(dot)se>, Peter Eisentraut <peter(at)eisentraut(dot)org> |
| Cc: | PostgreSQL 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 21:15:47 |
| Message-ID: | 1d6ffd13-3aa9-4b9a-adde-d1eb9af49a85@gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 14/01/26 17:57, Daniel Gustafsson wrote:
>> On 13 Jan 2026, at 15:16, Peter Eisentraut <peter(at)eisentraut(dot)org> wrote:
>
>> 2) A run-time setting (GUC) like experimental_pgq = on/off. This would be checked in the relevant DDL (CREATE/ALTER/DROP) commands as well as the GRAPH_TABLE function. So without that you couldn't do anything with it, but for example pg_dump and psql and ecpg preproc would still work and the system catalogs exist. Default to off for one release (subject to change).
>
> Such a GUC would IMHO only make sense if we remove it when we promote the
> feature, but removing a GUC also comes with a cost for anyone having baked it
> into their scripts etc. If we feel confident enough that a patch satisfies the
> security requirements to merge it, I think we should make it available.
>
Instead of having a GUC for each potential experimental feature we
could have just a single GUC with a list of experimental features that
are enabled.
SET enable_experimental_features = "foo,bar,baz";
--
Matheus Alcantara
EDB: https://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2026-01-14 21:20:58 | Re: Buffer locking is special (hints, checksums, AIO writes) |
| Previous Message | Andres Freund | 2026-01-14 21:12:04 | Re: Updating IPC::Run in CI? |