how to gate experimental features (SQL/PGQ)

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.

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