| From: | Daniel Gustafsson <daniel(at)yesql(dot)se> |
|---|---|
| To: | 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 20:57:32 |
| Message-ID: | 0CF8EED6-07A7-468B-A7A9-8BA1454F93C3@yesql.se |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> 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.
If a feature is deemed experimental in terms of it being feature completeness
(missing parts etc), or because user visible parts might change, then the
documentation is IMO the vehicle for handling that.
--
Daniel Gustafsson
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Daniel Gustafsson | 2026-01-14 20:59:02 | Re: how to gate experimental features (SQL/PGQ) |
| Previous Message | Jacob Champion | 2026-01-14 20:40:21 | Re: Updating IPC::Run in CI? |