Re: [PATCH] Introduce unified support for composite GUC options

út 23. 9. 2025 v 5:50 odesílatel Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> napsal:

> Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> writes:
> > Using GUC as session variables is a workaround because there is nothing
> > better. But it is not good solution
>
> Agreed, but we don't yet have a better one ...
>

but better GUC will not be good session variables

>
> > The basic question is if variables should be typed or typeless - like
> > plpgsql or psql variables.
>
> I think it is absolutely critical that GUCs *not* depend on the
> SQL type system in any way. That would be a fundamental layering
> violation, because we need to be able to read postgresql.conf
> before we can read catalogs --- not to mention that relevant type
> definitions might be different in different databases.
>
> I'm not sure that this point means much to the feature proposed in
> this thread, since IIUC it's proposing "use JSON no matter what".
> But it is a big problem for trying to use GUCs as session variables
> with non-built-in types.
>

This is a very important note - and it clearly describes the advantages
(and sense) of GUC.

GUC is good enough for work with text types - and our json is text type
based.
I can serialize and deserialize any array or composite to GUC but it has no
"nice" output in the SHOW command.

I can imagine an idea so the SET command can be able to evaluate simple
expressions (like arguments of CALL statements).
But it is not possible without a compatibility break. So right side of SET
command will be always reduced to value or list, and
I don't see a strong benefit to enhancing it gently.

>
> regards, tom lane
>