Re: [PATCH] Introduce unified support for composite GUC options
| От | David G. Johnston |
|---|---|
| Тема | Re: [PATCH] Introduce unified support for composite GUC options |
| Дата | |
| Msg-id | CAKFQuwYxZ=ObB44EM9UVn13ko8=QhtabeoJN+TCXPacmhgF-Xw@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: [PATCH] Introduce unified support for composite GUC options (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: [PATCH] Introduce unified support for composite GUC options
|
| Список | 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 по дате отправления: