Re: how to gate experimental features (SQL/PGQ)
| От | Matheus Alcantara |
|---|---|
| Тема | Re: how to gate experimental features (SQL/PGQ) |
| Дата | |
| Msg-id | 1d6ffd13-3aa9-4b9a-adde-d1eb9af49a85@gmail.com обсуждение исходный текст |
| Ответ на | Re: how to gate experimental features (SQL/PGQ) (Daniel Gustafsson <daniel@yesql.se>) |
| Ответы |
Re: how to gate experimental features (SQL/PGQ)
|
| Список | 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 по дате отправления: