Re: [PATCH] Introduce unified support for composite GUC options - Mailing list pgsql-hackers

From David G. Johnston
Subject Re: [PATCH] Introduce unified support for composite GUC options
Date
Msg-id CAKFQuwYxZ=ObB44EM9UVn13ko8=QhtabeoJN+TCXPacmhgF-Xw@mail.gmail.com
Whole thread Raw
In response to Re: [PATCH] Introduce unified support for composite GUC options  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [PATCH] Introduce unified support for composite GUC options
List pgsql-hackers
On Monday, September 22, 2025, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Чум=D0�к Ан�=82он <a.chumak@postgrespro.ru> writes:
> This patch adds a unified mechanism for declaring and using composite configuration options in GUC, eliminating the need to write a custom parser for each new complex data type.  New syntax for end user is json-like.

TBH, I think this is a bad idea altogether.  GUCs that would need
this are probably poorly designed in the first place; we should not
encourage inventing more.  I also don't love adding thousands of
lines of code without any use-case at hand.


Yeah, there is a decent height bar for me too.  The main functional benefit we’d get is that since both (multiple) settings are being given values simultaneously the check option code can enforce that only valid combinations are ever specified instead of generally needing runtime checks.

Beyond that, just use separate options with a naming scheme.

I can maybe see this for session variables masquerading as GUCs since we lack the former.  Something like wanting to store a JWT as-is in a GUC then referencing its components.

David J.

pgsql-hackers by date:

Previous
From: David Rowley
Date:
Subject: Re: Thoughts on NBASE=100000000
Next
From: Tomas Vondra
Date:
Subject: Re: Fix overflow of nbatch