Hi po 22. 9. 2025 v 23:31 odesílatel David G. Johnston < david.g.johns...@gmail.com> napsal:
> On Monday, September 22, 2025, Tom Lane <t...@sss.pgh.pa.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.chu...@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. > Using GUC as session variables is a workaround because there is nothing better. But it is not good solution - it doesn't to native format for data - all have to be text - composites are not compatible with native composites, arrays are not compatible with native composites - the GUC cannot be used simply in queries or expressions, and cannot be set as a result of query or expression - the GUC are not stable, so there can be some unwanted artefacts inside queries This patch has about 40% size like my session variables patches - and significantly less user documentation, significantly less regress tests - it does something else. The basic question is if variables should be typed or typeless - like plpgsql or psql variables. Typeless variables are more simple on implementation, but a) can be too primitive to store some more complex structures, or b) are not simple on implementation - and the complexity is very similar to typed variables. When variables are typed, then it is necessary to modify plan cache invalidation (what is not necessary for typeless variables). With its own catalog, the enhancing plan cache invalidation is simple and clean (because invalidation of plan cache is based on watching catalog changes), without catalog the plan cache invalidation is much more dirty work. Another question is the possibility to set different defaults for GUC by ALTER command. It can be an interesting, but very dangerous feature for session variables. GUC are great for configuration and holding possibly different defaults for role, database or system. PostgreSQL configuration is large, but it uses a very simple format, and I think it is working well. Regards Pavel > David J. > >
