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.