Re: [HACKERS] Configuration patch - Mailing list pgsql-patches

> pgsql@mohawksoft.com writes:
>>> AFAICS this patch breaks standalone backends, since the smarts involved
>>> in dealing with the new flavors of directory layouts were not taught to
>>> postgres.c.
>
>> 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.

See below
>
>> 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
>> "include."
>
> I like the idea of include.  I don't like this implementation.

OK.

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

OK, imagine this, maybe not right now, but in the future......

In the configuration file, one can load C code modules like in apache. Not
just SQL functions, but modules of functionality, like foreign table
types.
>
> 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
> wrongheaded.
>
> 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
>