Tom Lane wrote:

Bruce Momjian <[EMAIL PROTECTED]> writes:


In summary, I think we need to treat include specially in
postgresql.conf (no equals) and remove it as an actual GUC parameter and
just have it do includes immediately. (This will probably require
special-casing it in the guc-file grammar.)



Yes. In fact, it'll be a less-than-trivial change in guc-file, at least if you want the thing to act intuitively (that is, "include" acts like the target file is actually included right here). This will mean splitting ProcessConfigFile into a recursive read step followed by a nonrecursive apply step. Also, I think that invoking the flex lexer recursively will take a little bit of work.

I would suggest splitting the patch into two separate patches, one that
handles "include" and one that handles the other changes. The other
stuff is reasonably close to being ready to apply (modulo docs and
fixing the standalone-backend case), but "include" I think is still a
ways off.



One classic way to do include files is inside the lexer itself - at least that's the way I have always done it in the past. Then the client code doesn't need to know anything about it at all - it just sees a stream of lexemes with no idea what file they come from. Since inclusion can be done recursively, the lexer keeps a stack of files, of some reasonable size - in our case surely 5 or 10 would be a more than reasonable maximum recursion depth. You do need to keep track of the filename and line number for error reporting, though (use parallel stacks for those).


cheers

andrew


---------------------------(end of broadcast)--------------------------- TIP 7: don't forget to increase your free space map settings

Reply via email to