Re: gram.y=>preproc.y

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "David E(dot) Wheeler" <david(at)kineticode(dot)com>, Michael Meskes <meskes(at)postgresql(dot)org>, PostgreSQL Hacker <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: gram.y=>preproc.y
Date: 2008-11-10 20:09:45
Message-ID: 49189509.6090604@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:
> Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
>
>> I have had a quick look at it. The perl is more than ugly - it's
>> unmaintainable IMNSHO. It violates perl best practice in many ways, and
>> reflects the age of the a2p utility quite badly.
>>
>
>
>> There is no guarantee that the script won't have to be looked at.
>> Rather, the reverse is our experience, so this is a real consideration.
>>
>
>
>> I agree that a perl version is much more desirable, but it really
>> requires a hand translation from awk rather than a hacked a2p output.
>>
>
> IMHO awk was the wrong language to begin with, so I'd vote for a fresh
> implementation with re-thought data structures rather than just cleaning
> up around the edges.

That was what I was intending. The awk would just be a guide as to the
required logic.

> However, I would like any reimplementation to
> happen after we get this in, not before. As long as we are agreed that
> a perl script is the appropriate tool, someone can go off in a corner
> and reimplement without holding up anything else. And it's surely past
> time that Michael stops having to sync ecpg with the main grammar by
> hand.
>
>
>

Sure. No argument at all from me.

cheers

andrew

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Josh Berkus 2008-11-10 20:13:42 Re: SQL5 budget
Previous Message Tom Lane 2008-11-10 19:43:03 Re: Patch for ISO-8601-Interval Input and output.