Re: guc patch: Make variables fall back to default values

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: guc patch: Make variables fall back to default values
Дата
Msg-id 1944.1173795594@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: guc patch: Make variables fall back to default values  (Gregory Stark <stark@enterprisedb.com>)
Ответы Re: guc patch: Make variables fall back to default values  (Peter Eisentraut <peter_e@gmx.net>)
Re: guc patch: Make variables fall back to default values  (Joachim Wieland <joe@mcknight.de>)
Список pgsql-patches
Gregory Stark <stark@enterprisedb.com> writes:
> It's not just a bug. There's code missing.

> The code seems to assume that all custom variables are strings. There are
> about half a dozen Assert(variable->vartype == PGC_STRING) throughout the
> patch. That's not true, plperl's use_strict is a boolean and we have
> DefineCustome*Variable functions for each type of variable.

Well, they *are* strings as long as they're "custom".  Once a
DefineCustomFoo has been executed, there (should be) no difference
between a "custom" variable and a hard-wired one.

The thing that I was wondering about is the same Joachim mentioned: how
is it that the regression test ever worked?  The answer is that it's
not really testing custom variables, because it doesn't try to set
plperl.use_strict until after plperl has been loaded into the current
session.  So by that time the variable exists and should look like a
perfectly ordinary boolean GUC variable.  The fact that it doesn't look
like that says to me that there's something wrong with the patch logic,
over and above the question of what it should be Asserting.

            regards, tom lane

В списке pgsql-patches по дате отправления:

Предыдущее
От: Andrew Dunstan
Дата:
Сообщение: Re: guc patch: Make variables fall back to default values
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: guc patch: Make variables fall back to default values