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

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@eisentraut.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.

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.

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).

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