Tom Lane wrote:
>Bruce Momjian <pgman@candle.pha.pa.us> 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
