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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Gregory Stark <stark(at)enterprisedb(dot)com>
Cc: "Peter Eisentraut" <peter_e(at)gmx(dot)net>, pgsql-patches(at)postgresql(dot)org, "Joachim Wieland" <joe(at)mcknight(dot)de>
Subject: Re: guc patch: Make variables fall back to default values
Date: 2007-03-13 14:19:54
Message-ID: 1944.1173795594@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-patches

Gregory Stark <stark(at)enterprisedb(dot)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

In response to

Responses

Browse pgsql-patches by date

  From Date Subject
Next Message Peter Eisentraut 2007-03-13 14:33:17 Re: guc patch: Make variables fall back to default values
Previous Message Andrew Dunstan 2007-03-13 13:29:14 Re: guc patch: Make variables fall back to default values