Re: ECPG

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: Michael Meskes <meskes(at)postgresql(dot)org>, PostgreSQL Hacker <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: ECPG
Date: 2002-09-23 03:54:35
Message-ID: 14652.1032753275@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> Tom Lane wrote:
>> I had a thought about what to do with the ECPG grammar-too-big problem:
>> rather than depending on a beta release of bison, we could attack the
>> problem directly by omitting some of the backend grammar from what ECPG
>> supports.

> I think we should just go with the bison beta for ecpg and be done with
> it. If we find bugs, we can ask the bison folks to fix it, or work
> around it ourselves.

Using the beta bison has a lot of disadvantages though, particularly if
we want to follow the conservative route of using it only for ecpg and
not for the other .y files. How exactly will you cause the build to
work that way? How will you make it work for everyone who pulls CVS
rather than a prebuilt tar file?

Also, I was quite unthrilled when I experimented tonight with bison
1.49b, and found it to be a factor of 16 slower than bison 1.28.
(<2 seconds versus >32 seconds to process the backend gram.y file.)
If they don't fix that, bison 1.49+ will have roughly zero uptake
among real users --- who's going to hold still for that much slowdown,
to get a tool whose only obvious improvement is that it now rejects
optional commas?

Bottom line is that I don't think we can require bison > 1.28 for a
good while yet.

regards, tom lane

In response to

  • Re: ECPG at 2002-09-23 00:48:54 from Bruce Momjian

Browse pgsql-hackers by date

  From Date Subject
Next Message Christopher Kings-Lynne 2002-09-23 03:59:29 European Vacation
Previous Message Tom Lane 2002-09-23 03:21:42 Re: PGXLOG variable worthwhile?