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

Hi,

On 2026-01-13 15:16:22 +0100, Peter Eisentraut 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@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.

Yikes, large indeed:

$ git diff --shortstat upstream/master
 118 files changed, 14805 insertions(+), 220 deletions(-)

$ git log -p upstream/master.. |wc -c
721659

I think the main question that needs answering is not how to get this merged,
but whether a feature this large (in its infancy stage!) is worth the
squeeze...


It's possible that I am just weak minded, but at least I can't sensibly review
a 700kB sized commit. This imo badly needs to broken down and, if at all
possible, reduced in size & scope.


> Also, it should not significantly affect uses that don't use that feature.

Are there such affects currently?


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

I don't even know how you could implement 3) realistically. We have zero
infrastructure for making e.g. parser, keyword list etc change due to defines
compile time.


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

I'm quite sceptical that that's a good choice for an experimental feature
being merged, because it has tree wide impact, e.g. due to making pg_attribute
wider, affecting the protocol, adding branches to pretty core places.


I think I am on board with being more open to merge features earlier, but it
shouldn't be a fig leaf to allow merging stuff with wide impact with the
excuse that it's an experimental thing.

Greetings,

Andres Freund