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

From Bruce Momjian
Subject Re: guc patch: Make variables fall back to default values
Date
Msg-id 200703222058.l2MKw9V09328@momjian.us
Whole thread Raw
In response to Re: guc patch: Make variables fall back to default values  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: guc patch: Make variables fall back to default values  (Joachim Wieland <joe@mcknight.de>)
List pgsql-patches
Is there a new version of this patch being worked on?

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

Tom Lane wrote:
> Joachim Wieland <joe@mcknight.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@momjian.us>          http://momjian.us
  EnterpriseDB                               http://www.enterprisedb.com

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

pgsql-patches by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: xpath_array with namespaces support
Next
From: Peter Eisentraut
Date:
Subject: Re: xpath_array with namespaces support