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

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

Joachim Wieland wrote:
> On Tue, Mar 13, 2007 at 08:22:17AM +0000, Gregory Stark wrote:
>
>> 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. Perl bombs
>> because plperl.use_strict is a boolean.
>>
>
> The attached patch removes those Asserts.
>
> But this is not the whole story. I wonder why setting "plperl.use_strict"
> is supposed to work at all? Where is the corresponding definition of
> "plperl" as a custom variable class? I can add it manually to
> postgresql.conf and make the regression tests work but is this the intended
> way?
>
>
>

The whole custom variable gadget is a mess, IMNSHO, and almost
completely undocumented. If anyone comes up with a sane, workable and
documented design I'll be happy.

As I understand the way custom variable class works (or is supposed to
work), you need it if the variable is set in advance of the call to
define it (e.g. in postgresql.conf) but not if you set if after.

cheers

andrew

In response to

Browse pgsql-patches by date

  From Date Subject
Next Message Tom Lane 2007-03-13 14:19:54 Re: guc patch: Make variables fall back to default values
Previous Message Heikki Linnakangas 2007-03-13 12:38:31 Re: Recalculating OldestXmin in a long-running vacuum