> On 14 Jan 2026, at 22:15, Matheus Alcantara <matheusssilv97@gmail.com> wrote:
>
> 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
experimentalfeatures that are enabled.
>
> SET enable_experimental_features = "foo,bar,baz";
That is an option to avoid the need to retire/remove GUC's. Such a format
makes it harder to know which experimental features which are disabled when
querying pg_settings or looking at it in other ways where the postgresql.conf
comment isn't immediately visible, but that might not be a big concern.
--
Daniel Gustafsson
