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

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Gregory Stark <stark(at)enterprisedb(dot)com>, 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:47:40
Message-ID: 200703131547.41285.peter_e@gmx.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-patches

Tom Lane wrote:
> 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.

I think that the sole purpose of c_v_c is to allow custom variables in
the configuration file, because that is possibly read before modules
are loaded. Basically it just means that "prefix.*" is not rejected.
In a session, it doesn't make a difference what c_v_c is set to; the
variable needs to be registered period. However, if the registration
code runs only when the module is invoked for the first time rather
than at the start of the session (as in the case of plperl), then it's
apparently impossible to set a variable in a session before the first
call. It's all very weird.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

In response to

Browse pgsql-patches by date

  From Date Subject
Next Message Joachim Wieland 2007-03-13 15:05:39 Re: guc patch: Make variables fall back to default values
Previous Message Peter Eisentraut 2007-03-13 14:33:17 Re: guc patch: Make variables fall back to default values