On Tue, Mar 13, 2007 at 10:19:54AM -0400, Tom Lane wrote: > Gregory Stark <[EMAIL PROTECTED]> writes: > > It's not just a bug. There's code missing.
> > The code seems to assume that all custom variables are strings. There are > > about half a dozen Assert(variable->vartype == PGC_STRING) throughout the > > patch. That's not true, plperl's use_strict is a boolean and we have > > DefineCustome*Variable functions for each type of variable. > 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. > 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. So by that time the variable exists and should look like a > perfectly ordinary boolean GUC variable. The fact that it doesn't look > like that says to me that there's something wrong with the patch logic, > over and above the question of what it should be Asserting. What is wrong is that plperl defines a variable that is a mix of a guc variable and a custom variable. It claims being a custom variable by setting var->group = CUSTOM_OPTIONS but it does not set the respective custom_variable_class and so by definition it can't be a custom variable. Joachim ---------------------------(end of broadcast)--------------------------- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate