Re: [PATCH] Introduce unified support for composite GUC options
| От | Pavel Stehule |
|---|---|
| Тема | Re: [PATCH] Introduce unified support for composite GUC options |
| Дата | |
| Msg-id | CAFj8pRDHLVRPgca-BVn1axpD7ZQWfwLxPJ1hqLdiQbr2d4Su5w@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: [PATCH] Introduce unified support for composite GUC options (Tom Lane <tgl@sss.pgh.pa.us>) |
| Список | pgsql-hackers |
út 23. 9. 2025 v 5:50 odesílatel Tom Lane <tgl@sss.pgh.pa.us> napsal:
Pavel Stehule <pavel.stehule@gmail.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
В списке pgsql-hackers по дате отправления: