[EMAIL PROTECTED] writes:
>> AFAICS this patch breaks standalone backends, since the smarts involved
>> in dealing with the new flavors of directory layouts were not taught to
> Hmm, I guess its time to get a CVS version of PG. This was originally done
> in 7.3 and migrated to 7.4. 7.5 is substantially different?
The same issue applied in 7.4 and before; but yes, all that code looks
noticeably different in CVS tip.
> As for include not being a variable, no it isn't. It is a new class of GUC
> parameter. Would you like a better syntax?
As I said, I think this "class of GUC parameter" is ill-considered.
> FWIW: This is exactly the same syntax that was discussed, and no one
> brought up that it was a problem. You even said you liked the idea of
I like the idea of include. I don't like this implementation.
> I wanted to create a generic facility for "smarter" configuration. Being
> able to create functions and pass parameters should allow smaller more
> focused configuration parsing.
I don't believe "include" is a representative of a class; it seems a
specialized one-of-a-kind thing. If you had one or two more examples
of this class then I might think you are onto something, but as-is
there is no reason to think that you've got a well-defined idea or
have made the right decisions about how it should work.
Basically, include is not a variable because neither "set include" nor
"show include" are sensible operations at all. Implementing it in a way
that makes you have to deal with these possibilities is simply
Another reason why it's not a variable is that processing it as a
variable means the sub-file is not read in the order that the user would
naturally expect; with the implementation as you have it, the behavior
would be quite surprising as to which file wins if both outer file and
subfile set the same variable. (Take another look at guc-file.l: it
eats the whole file and only then starts to evaluate variables.)
What I'd think is reasonable is a special case hack in guc-file.l that
checks for opt_name = "include" and does something immediately upon
seeing it. (CVS tip has a special hack for "custom_variable_classes"
here, which has got problems of its own because that *is* a variable,
but that's right around where I'd envision inserting code for include.)
> I'm open to suggestions. Would you prefer stating the function parameters
> with a special character? '#' is taken, how about '!' ? is in:
It's not the syntax I'm objecting to; it's the implementation.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match