Perl code thats readable and maintainable ;-)
In reality - it doesn't look too disimilar from the awk original. I didn't appreciate that we'd probably need to keep 2 versions (one for unix and one for windows). In that case - I'd argue that we only need to "maintain" one and regenerate the other when required. Provided they both work the same, I'd say it doesn't matter what the perl one looked like, because thats not the one that'd be maintained :-) Personally - I'd be tempted to keep this as a background process for the ecpg maintiner anyway rather than a normal end user. Probably using something like a 'syncparser' make target and keep the generation separate from the normal build process. That way - awk/perl (you could then pick just one) would only be a requirement if you want to regenerate the grammer via the 'syncparser' target. This does have the benefit that the ecpg maintainer can then control when the sync'ing is done and that its less likely to inadvertantly break the ecpg branch of source tree. At the end of the day - this is something Michael has just been doing manually already and we're trying to help automate the process.. (ducks for cover) > As against that ... does a2p produce code that is readable/maintainable? > If the code wasn't perl to start with I'd be a little worried about > ending up with ugly hard-to-read code. -- Mike Aubury http://www.aubit.com/ Aubit Computing Ltd is registered in England and Wales, Number: 3112827 Registered Address : Clayton House,59 Piccadilly,Manchester,M1 2AQ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
