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
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 |