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

From Akim Demaille
Subject Re: Remove useless associativity/precedence from parsers
Date
Msg-id 766895B5-236F-4588-961D-E004E9D21D56@lrde.epita.fr
Whole thread Raw
In response to Re: Remove useless associativity/precedence from parsers  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Remove useless associativity/precedence from parsers
Re: Remove useless associativity/precedence from parsers
List pgsql-hackers
Hi Tom!

> Le 20 mai 2019 à 15:54, Tom Lane <tgl@sss.pgh.pa.us> a écrit :
>
> Akim Demaille <akim@lrde.epita.fr> writes:
>> It is for the same reasons that I would recommend not using associativity directives (%left, %right, %nonassoc)
whereassociativity plays no role: %precedence is made for this.  But it was introduced in Bison 2.7.1 (2013-04-15), and
Idon't know if requiring it is acceptable to PostgreSQL. 
>
> 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.

> I believe our (documented and tested)
> minimum version of Bison is still 1.875.  While we'd be willing
> to move that goalpost if there were clear benefits from doing so,
> I'm not even convinced that %precedence as you describe it here
> is any improvement at all.

Ok.  I find this really surprising: you are leaving dormant directives
that may fire some day without anyone knowing.

You could comment out the useless associativity/precedence directives,
that would just as well document them, without this risk.

But, Ok, that's only my opinion.


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?


pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: VACUUM fails to parse 0 and 1 as boolean value
Next
From: Andres Freund
Date:
Subject: Re: Create TOAST table only if AM needs