Re: automatic parser generation for ecpg

From: David Fetter <david(at)fetter(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Mike Aubury <mike(dot)aubury(at)aubit(dot)com>, Michael Meskes <meskes(at)postgresql(dot)org>, PostgreSQL Hacker <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: automatic parser generation for ecpg
Date: 2008-10-21 15:45:11
Message-ID: 20081021154511.GH1906@fetter.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Oct 21, 2008 at 08:31:54AM -0400, Tom Lane wrote:

> So it's all pretty messy and neither choice is exactly desirable. I
> think maintaining parallel versions of an ecpg parser generator
> would be no fun at all, though, so the perl choice seems more or
> less forced. We could either preserve the current state of play by
> shipping the derived bison file in tarballs, or bite the bullet and
> say perl is required to build from source in all cases (in which
> case I'd be inclined to try to get rid of Gen_fmgrtab.sh etc).

+1 for requiring it for source builds. We'll be able to simplify the
code quite a bit :)

> As against that ... does a2p produce code that is
> readable/maintainable?

Not that I've seen. There are modules on CPAN (I know, I know) for
dealing with lexx and yacc, and those are probably better for the
purpose.

Cheers,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jim 'Decibel!' Nasby 2008-10-21 15:45:43 Regression in IN( field, field, field ) performance
Previous Message Martijn van Oosterhout 2008-10-21 15:41:25 Re: SSL cleanups/hostname verification