Robert Haas <robertmhaas@gmail.com> writes:
> One fairly major obstacle to using quex for anything is that it
> doesn't appear to be packaged on either Fedora or Ubuntu (I tried
> apt-cache search quex on my Ubuntu laptop, and yum install quex on an
> F16 machine). 'port install quex' on my MacOS X doesn't find it
> either. This means that if we were to switch to quex, the barrier to
> compiling PostgreSQL would go up very significantly. I realize
> there's a chicken-and-egg problem there, since if quex is awesome and
> nobody uses it because it isn't packaged, then it will never become
> popular enough for anyone to consider packaging it. Nonetheless, I'm
> not sure I want to be the guinea pig.
I was trying to think of a delicate way to put that, but since you
beat me to it ... yeah, exactly. It's possible that quex is so
spectacular that we'd be willing to absorb the conversion costs
and the penalties of being a pioneer user of a new tool, but the bar
seems pretty high.
> Even if the actual
> patch-as-committed-to-git to make the switch to quex were not that
> large, the amount of follow-on work we'd be creating for every
> developer and packager of PostgreSQL would be quite formidable.
FWIW, I think only developers not packagers would really be taking such
a hit. I assume we'd continue to ship prebuilt lexer output in
tarballs, so there'd seldom be a reason for a packager to need to run
the tool. Given the extremely slow rate of churn of the lexer, it might
not be necessary for most developers to have the tool installed, either,
if we were willing to put the derived file into git.
Having said all that, if the amount of effort needed to make a trial
port is within reason, by all means let's try it and see what the
performance difference is, rather than just speculating.
regards, tom lane
