Michael Meskes <meskes@postgresql.org> writes:
> ... The only manual work I see in the
> future is adding some special ecpg handling. I fully expect this script to
> generate a working parser for every single change in gram.y. However, if some
> new rule needs a different aka non-default handling in ecpg that will remain
> manual, but the automatic process should nevertheless create a parser with
> default handling for this new rule, thus not breaking anything but the new
> feature in ecpg, which of course cannot get broken because it is new.
Hmm --- I hadn't really thought much about the need for the generation
script to make special transformations of some rules, but obviously that
is going to be needed in the places where you have to sew the SQL and
ecpg syntaxes together. Perhaps there is a good argument for going to
perl just to be sure that we don't get backed into a corner on what can
be done in such cases. awk is a great tool for certain kinds of tasks,
but it's pretty limited. For instance, AFAIK you'd be out of luck if
you needed to make two passes over the input.
So my vote at this point would be to convert the script to perl.
Also, never mind the idea about starting to require perl for all build
scenarios. We'll still ship preproc.y in tarballs because we will still
ship preproc.c in tarballs --- I don't think anyone was lobbying to
start requiring bison to be present for builds from tarballs. So if
the script is perl we'll have exactly the same build dependency
scenarios as now.
regards, tom lane
