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

Поиск
Список
Период
Сортировка
Искать
От
Tom Lane
Тема
Re: [PATCH] Introduce unified support for composite GUC options
Дата
Msg-id
3014217.1758599440@sss.pgh.pa.us
Ответ на
Список
Дерево обсуждения
[PATCH] Introduce unified support for composite GUC options Чумак Антон <a.chumak@postgrespro.ru>
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 "David G. Johnston" <david.g.johnston@gmail.com>
Re: [PATCH] Introduce unified support for composite GUC options Pavel Stehule <pavel.stehule@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 Pavel Stehule <pavel.stehule@gmail.com>
Re: [PATCH] Introduce unified support for composite GUC options Чумак Антон <a.chumak@postgrespro.ru>
Re: [PATCH] Introduce unified support for composite GUC options Pavel Stehule <pavel.stehule@gmail.com>
Re: [PATCH] Introduce unified support for composite GUC options Чумак Антон <a.chumak@postgrespro.ru>
Re: [PATCH] Introduce unified support for composite GUC options Pavel Stehule <pavel.stehule@gmail.com>
Re: [PATCH] Introduce unified support for composite GUC options Чумак Антон <a.chumak@postgrespro.ru>
Re: [PATCH] Introduce unified support for composite GUC options Pavel Stehule <pavel.stehule@gmail.com>
Re: [PATCH] Introduce unified support for composite GUC options "David G. Johnston" <david.g.johnston@gmail.com>
Re: [PATCH] Introduce unified support for composite GUC options Tom Lane <tgl@sss.pgh.pa.us>
Pavel Stehule  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 ...

> 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.

			regards, tom lane


В списке pgsql-hackers по дате отправления
От: Pavel Stehule
Дата:
От: Pavel Stehule
Дата:
FAQ