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

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Joachim Wieland <joe(at)mcknight(dot)de>, Gregory Stark <stark(at)enterprisedb(dot)com>, 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-22 20:58:09
Message-ID: 200703222058.l2MKw9V09328@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-patches


Is there a new version of this patch being worked on?

---------------------------------------------------------------------------

Tom Lane wrote:
> Joachim Wieland <joe(at)mcknight(dot)de> writes:
> > On Tue, Mar 13, 2007 at 11:52:38AM -0400, Tom Lane wrote:
> >> Why do you need to tell that? IMHO, once the DefineCustomFoo function
> >> has been executed, it should be exactly like any other variable (other
> >> than having a funny name).
>
> > For example for the fall-back-to-default patch. I might not need to tell if
> > it has been introduced by one of the DefineCustomFoo functions but for the
> > "other" custom variables. Imagine that we have defined a custom variable via
> > the configuration file, remove it and send SIGHUP. My understanding is that
> > this variable should then be deleted from the pool of valid variables
> > because it falls back to its default value and the default value of a custom
> > variable is its non-existance.
>
> Once DefineCustomFoo has been executed, you have a reset value to fall
> back to. I think what you really want is to recognize variables that
> are in the placeholder state, and have them go away as above.
> For that you check the GUC_CUSTOM_PLACEHOLDER flag. In any case there
> must never be any use of var->group for decision making; that's simply
> wrong.
>
> However, ISTM that forcing variables to go away is useless extra code.
> What purpose does it serve? Not error checking, because you already
> accepted the variable before. Surely you wouldn't argue that, say,
> reverting to a prior setting of check_function_bodies should cause the
> system to go back and validate a CREATE FUNCTION command it has already
> accepted. Moreover, while you could perhaps argue that the "principle
> of least surprise" cuts either way here, it seems to me there's a good
> argument for not throwing away variables: you might be discarding data
> the user needed. So I'd vote for just leaving them there.
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: In versions below 8.0, the planner will ignore your desire to
> choose an index scan if your joining column's datatypes do not
> match

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

In response to

Responses

Browse pgsql-patches by date

  From Date Subject
Next Message Peter Eisentraut 2007-03-22 20:58:36 Re: xpath_array with namespaces support
Previous Message Peter Eisentraut 2007-03-22 20:55:24 Re: [PATCHES] xpath_array with namespaces support