Re: automatic parser generation for ecpg

Поиск
Список
Период
Сортировка
От David Fetter
Тема Re: automatic parser generation for ecpg
Дата
Msg-id 20081021154511.GH1906@fetter.org
обсуждение исходный текст
Ответ на Re: automatic parser generation for ecpg  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: automatic parser generation for ecpg  (Michael Meskes <meskes@postgresql.org>)
Список 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@fetter.org> http://fetter.org/
Phone: +1 415 235 3778  AIM: dfetter666  Yahoo!: dfetter
Skype: davidfetter      XMPP: david.fetter@gmail.com

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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Martijn van Oosterhout
Дата:
Сообщение: Re: SSL cleanups/hostname verification
Следующее
От: Jim 'Decibel!' Nasby
Дата:
Сообщение: Regression in IN( field, field, field ) performance