Re: [HACKERS] Re: [PATCHES] Patch for more readable parse error messages - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] Re: [PATCHES] Patch for more readable parse error messages
Date
Msg-id 22061.951191794@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] Re: [PATCHES] Patch for more readable parse error messages  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: [HACKERS] Re: [PATCHES] Patch for more readable parse error messages  (Bruce Momjian <pgman@candle.pha.pa.us>)
Re: [HACKERS] Re: [PATCHES] Patch for more readable parse error messages  (Don Baccus <dhogaza@pacifier.com>)
Re: [HACKERS] Re: [PATCHES] Patch for more readable parse error messages  (Peter Eisentraut <e99re41@DoCS.UU.SE>)
List pgsql-hackers
Peter Eisentraut <peter_e@gmx.net> writes:
> On 2000-02-20, Tom Lane mentioned:
>> I would not like us to stop working
>> with non-bison yaccs, since bison's output depends on alloca() which
>> is not available everywhere.

> Couldn't alloca(x) be defined to palloc(x) where missing?

Probably, but I wasn't looking for a workaround; that was just one
quick illustration of a reason not to want to use bison (one that's
bitten me personally, so I knew it offhand).  We should try not to
become dependent on bison when there are near-equivalent tools, just
on general principles of maintaining portability.  For an analogy,
I believe most of the developers use gcc, but it would be a real bad
idea for us to abandon support for other compilers.

For the same sort of reasons I'd prefer that our scanner worked
with vanilla lex, not just flex.  I'm not sure how far away we are
from that; it may be an unrealistic goal.  But if it is within reach
then we shouldn't give it up lightly.
        regards, tom lane


pgsql-hackers by date:

Previous
From: "Hiroshi Inoue"
Date:
Subject: RE: [HACKERS] Numeric with '-'
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] Numeric with '-'