út 23. 9. 2025 v 5:50 odesílatel Tom Lane <[email protected]> napsal:
> Pavel Stehule <[email protected]> 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 >
