Re: Remove useless associativity/precedence from parsers - Mailing list pgsql-hackers

Akim Demaille <akim@lrde.epita.fr> writes:
>> Le 20 mai 2019 à 15:54, Tom Lane <tgl@sss.pgh.pa.us> a écrit :
>> 2013?  Certainly not.  We have a lot of buildfarm critters running
>> older platforms than that.

> This I fully understand.  However, Bison is a source generator,
> and it's quite customary to use modern tools on the maintainer
> side, and then deploy the result them on possibly much older
> architectures.
> Usually users of Bison build tarballs with the generated parsers
> in them, and ship/test from that.

As do we, but at the same time we don't want to make our tool
requirements too onerous.  I think that really the practical limit
right now is Bison 2.3 --- Apple is still shipping that as their system
version, so requiring something newer than 2.3 would put extra burden
on people doing PG development on Macs (of which there are a lot).
The fact that we still test 1.875 is mostly just an "if it ain't broke
don't break it" thing, ie don't move the goalposts without a reason.

> So Bison, and your use of it today, is exactly what you need?
> There's no limitation of that tool that you'd like to see
> address that would make it a better tool for PostgreSQL?

Well, there are a couple of pain points, but they're not going to be
addressed by marginal hacking on declarations ;-).  The things that
we find really painful, IMV, are:

* Speed of the generated parser could be better.  I suspect this has
a lot to do with the fact that our grammar is huge, and so are the
tables, and that causes lots of cache misses.  Maybe this could be
addressed by trying to make the tables smaller and/or laid out in
a way with better cache locality?

* Lack of run-time extensibility of the parser.  There are many PG
extensions that wish they could add things into the grammar, and can't.
This is pretty pie-in-the-sky, I know.  One of the main reasons we stick
to Bison is the compile-time grammar sanity checks it provides, and
it's not apparent how to have that and extensibility too.  But it's
still a pain point.

* LALR(1) parsing can only barely cope with SQL, and the standards
committee keeps making it harder.  We've got some hacks that fake
an additional token of lookahead in some places, but that's just an
ugly (and performance-eating) hack.  Maybe Bison's GLR mode would
already solve that, but no one here has really looked into whether
it could improve matters or whether it'd come at a performance cost.
The Bison manual's description of GLR doesn't give me a warm feeling
either about the performance impact or whether we'd still get
compile-time warnings about bogus grammars.

Other PG hackers might have a different laundry list, but that's mine.

            regards, tom lane