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

From Matheus Alcantara
Subject Re: how to gate experimental features (SQL/PGQ)
Date
Msg-id 1d6ffd13-3aa9-4b9a-adde-d1eb9af49a85@gmail.com
Whole thread Raw
In response to Re: how to gate experimental features (SQL/PGQ)  (Daniel Gustafsson <daniel@yesql.se>)
Responses Re: how to gate experimental features (SQL/PGQ)
List pgsql-hackers
On 14/01/26 17:57, Daniel Gustafsson wrote:
>> 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.
> 
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



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Updating IPC::Run in CI?
Next
From: Andres Freund
Date:
Subject: Re: Buffer locking is special (hints, checksums, AIO writes)