Re: Remove useless associativity/precedence from parsers

hi Tom!

> Le 23 mai 2019 à 00:29, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> a écrit :
>
> Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com> writes:
>> On 5/21/19 11:49 AM, Akim Demaille wrote:
>>> Usually users of Bison build tarballs with the generated parsers
>>> in them, and ship/test from that.
>
>> The buildfarm client does not build from tarballs, it builds from git,
>> meaning it has to run bison. Thus Tom's objection is quite valid, and
>> your dismissal of it is not.

I had not realized I had been rude to anybody. I apologize to
Tom, I did not mean to dismiss anything.

> Right, but that's a much narrower set of people who need to update
> than "all PG users" or even "all PG developers".
>
> I checked the buildfarm's configure results not too long ago, and noted
> that the oldest bison versions are
>
> gaur | configure: using bison (GNU Bison) 1.875
> prairiedog | configure: using bison (GNU Bison) 1.875
> dromedary | configure: using bison (GNU Bison) 2.3
> locust | configure: using bison (GNU Bison) 2.3
> longfin | configure: using bison (GNU Bison) 2.3
> nudibranch | configure: using bison (GNU Bison) 2.3
> anole | configure: using bison (GNU Bison) 2.4.1
> fulmar | configure: using bison (GNU Bison) 2.4.1
> gharial | configure: using bison (GNU Bison) 2.4.1
> grouse | configure: using bison (GNU Bison) 2.4.1
> koreaceratops | configure: using bison (GNU Bison) 2.4.1
> leech | configure: using bison (GNU Bison) 2.4.1
> magpie | configure: using bison (GNU Bison) 2.4.1
> treepie | configure: using bison (GNU Bison) 2.4.1
> coypu | configure: using bison (GNU Bison) 2.4.3
> friarbird | configure: using bison (GNU Bison) 2.4.3
> nightjar | configure: using bison (GNU Bison) 2.4.3
> (then 2.5 and later)
>
> (This doesn't cover the Windows members, unfortunately.)
>
> gaur and prairiedog are my own pet dinosaurs, and updating them would
> not be very painful.

I don't want to be painful, but the fact that the buildfarm
starts from git is also a design choice. In order to be
fully reproducible, I know projects that have a first step
that builds the end-user type of tarball, and run it on all
sorts of architectures. Of course, it's more initial set up,
but you gain your independence on many tools which in turn
makes it easier to check on more architectures.

> Still, the bottom line here is that we could require a new(ish) Bison
> if we could point to clear benefits that outweigh the pain. Right
> now there's not much argument for it.

I get that, thanks.

Cheers!