Peter Eisentraut <peter_e@gmx.net> writes:
> Am Donnerstag, 16. Februar 2006 02:50 schrieb Tom Lane:
>> The m4 idea seems attractive to me because that's already effectively
>> required as part of the autoconf infrastructure (and I think bison
>> uses it too these days).
> That is true, but I'm afraid that this will lead to code that only a few
> people will be able to maintain. (Try programming a loop in m4 to start.)
>> A similar issue that's been bothering me for awhile is that it'd be a
>> lot less error prone if keywords.c and the keyword list productions in
>> gram.y were generated off a common declarative source (which might as
>> well produce the keyword documentation appendix too).
> That could be a job for m4, I think.
Hmm ... well, if we are going to do this other thing with xsltproc, the
keyword problem should probably be solved with the same tool.
I hesitate to mention this, but: we have several other derived files in
the tarball (postgres.bki, fmgroids.h, etc) and those are all built with
shell/awk/sed/perl scripts. How out of the question is it to solve the
GUC problem with that technology?
regards, tom lane