Re: how to gate experimental features (SQL/PGQ) - Mailing list pgsql-hackers

From Daniel Gustafsson
Subject Re: how to gate experimental features (SQL/PGQ)
Date
Msg-id 0CF8EED6-07A7-468B-A7A9-8BA1454F93C3@yesql.se
Whole thread Raw
In response to how to gate experimental features (SQL/PGQ)  (Peter Eisentraut <peter@eisentraut.org>)
Responses Re: how to gate experimental features (SQL/PGQ)
Re: how to gate experimental features (SQL/PGQ)
List pgsql-hackers
> On 13 Jan 2026, at 15:16, Peter Eisentraut <peter@eisentraut.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
forexample 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




pgsql-hackers by date:

Previous
From: Jacob Champion
Date:
Subject: Re: Updating IPC::Run in CI?
Next
From: Daniel Gustafsson
Date:
Subject: Re: how to gate experimental features (SQL/PGQ)