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. +