Re: [HACKERS] Re: [PATCHES] Patch for more readable parse error messages

At 10:56 PM 2/21/00 -0500, Tom Lane wrote:
>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.

I agree entirely with the above.  The more portable the tool, the larger
the potential user base.   Unless the goal is to bundle-up Postgres with
a pre-defined set of software, i.e. GNU in this case (despite the fact
that I don't see Postgres on their site as part of their list of open-source
software, and I think I looked twice), go for the cover-the-earth approach.

SQL syntax isn't particularly difficult.  On the other hand, I realize there's
a legacy to support.  Still, making portions of the product dependent on one
tool or another is an issue that merits close scrutiny.  Shouldn't be done 
except under compelling reasons.

I mean, presuming a reasonably modern C, C tools, and large-scale 
operating-system environment makes sense (no reason to run native on a palm
pilot,
at this point).  But unecessary dependence on particular tools when not
necessary doesn't make much sense.

Just IMO, of course.



- Don Baccus, Portland OR <dhogaza@pacifier.com> Nature photos, on-line guides, Pacific Northwest Rare Bird Alert
Serviceand other goodies at http://donb.photo.net.