Re: guc patch: Make variables fall back to default values - Mailing list pgsql-patches

From Tom Lane
Subject Re: guc patch: Make variables fall back to default values
Date
Msg-id 1944.1173795594@sss.pgh.pa.us
Whole thread Raw
In response to Re: guc patch: Make variables fall back to default values  (Gregory Stark <stark@enterprisedb.com>)
Responses 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>)
List 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 by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: guc patch: Make variables fall back to default values
Next
From: Peter Eisentraut
Date:
Subject: Re: guc patch: Make variables fall back to default values