From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Чумак Антон <a(dot)chumak(at)postgrespro(dot)ru>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: [PATCH] Introduce unified support for composite GUC options |
Date: | 2025-09-22 21:30:59 |
Message-ID: | CAKFQuwYxZ=ObB44EM9UVn13ko8=QhtabeoJN+TCXPacmhgF-Xw@mail.gmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Monday, September 22, 2025, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> =?utf-8?q?=D0=A7=D1=83=D0=BC=D0=B0=D0=BA_=D0=90=D0=BD=D1=82=D0=BE=D0=BD?=
> <a(dot)chumak(at)postgrespro(dot)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.
From | Date | Subject | |
---|---|---|---|
Next Message | Tomas Vondra | 2025-09-22 21:31:31 | Re: Fix overflow of nbatch |
Previous Message | David Rowley | 2025-09-22 21:19:28 | Re: Thoughts on NBASE=100000000 |