On Tue, Mar 13, 2007 at 11:08:52AM -0400, Tom Lane wrote: > Joachim Wieland <[EMAIL PROTECTED]> writes: > > On Tue, Mar 13, 2007 at 10:19:54AM -0400, Tom Lane wrote: > >> Well, they *are* strings as long as they're "custom". Once a > >> DefineCustomFoo has been executed, there (should be) no difference > >> between a "custom" variable and a hard-wired one.
> > The code in question is the only place that calls one of the > > DefineCustom*Variable functions. But those functions set > > var->group = CUSTOM_OPTIONS what makes variables look like custom variables > > defined via SQL or the config file but in reality they aren't. Hence the > > confusion of the type assertion. > My point here that you shouldn't be using var->group to make any > semantic choices. That's supposed to be a label for user convenience, > nothing else. Then what is the criterion to tell what is a custom variable and what isn't? If it contains a dot in the name it is? This wouldn't resolve the problem at hand either... :-( We might have to think about custom variables as a whole, what we have now seems like a very unclear definition and everybody has his own opinion about what it is and how it works (and I'm not excluding myself here :-)). Joachim ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly