Re: how to gate experimental features (SQL/PGQ)

On Tue, Jan 13, 2026 at 10:16 PM Peter Eisentraut <peter(at)eisentraut(dot)org> wrote:
>
> Some of you will have seen the thread on the SQL/PGQ feature patch.[0]
> I want to evaluate how it would be acceptable to commit such a feature
> patch with an understanding that it is experimental. Perhaps some of
> these ideas could then also be applied to other projects.
>
> [0]:
> https://www.postgresql.org/message-id/flat/a855795d-e697-4fa5-8698-d20122126567(at)eisentraut(dot)org
>
> At this point, the patch set is pretty settled, but it is large, and
> it's not going to be perfect at the first try. Especially, some of the
> parsing rules, query semantics, that kind of thing. Imagine if you
> implemented basic SQL for the first time, how sure would you be that you
> get the semantics of a.b.c fully correct everywhere at the first try.
> But much of the patch is almost-boilerplate: New DDL commands, new
> catalogs, associated tests and documentation. It looks a lot, but most
> of it is not very surprising. So it might make sense to commit this and
> let it get refined in-tree rather than carrying this large patch around
> until some indefinite point.

+1

>
> Obviously, there would be some basic requirements. The overall code
> structure should be future-proof. It shouldn't crash. It has to
> satisfy security requirements. Also, it should not significantly affect
> uses that don't use that feature. All of this is being worked on. But
> I would like to communicate to users, the details of some query results
> might change, we might make some incompatible syntax changes if there
> was some mistake, or I don't know, maybe the planning of some query
> creates an infinite loop that we haven't caught. I'm not aware of
> anything like that, but it seems prudent to plan for it.

Since the patch set doesn't support VLE(variable length edge) yet, I don't
think it will cause an infinite loop.

>
> Some options:
>
> 1) Just document it and hope people will read the documentation and/or
> understand that it's a new feature that needs time to mature.
>
> 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).

Instead of a GUC, does it make sense to just raise a notice message for
those DDL?

>
> 3) A compile-time option.
>
> My preference would be 2). Option 3) has obvious problems, like you
> wouldn't get buildfarm coverage, and it would be a significant burden on
> all developers to keep the different code paths all working going
> forward. Option 1) would be the easy fallback, but I suppose the point
> of this message is to check whether a more technical approach would be
> preferable.
>
> Also, perhaps others have had similar thoughts about other development
> projects, in which case it would be good to get an overview and think
> about how these principles could be applied in a general way.
>
> Just to put forward another example that I'm familiar with, I have this
> currently-dormant column encryption patch set [1] that has vaguely
> similar properties in that it is a large patch, lots of boilerplate,
> lots of details that are best checked while actually using it, but
> possibly requiring incompatible changes if fixes are required.
>
> [1]:
> https://www.postgresql.org/message-id/flat/89157929-c2b6-817b-6025-8e4b2d89d88f%40enterprisedb.com
>
>
>

--
Regards
Junwang Zhao