Re: Remove useless associativity/precedence from parsers

Поиск
Список
Период
Сортировка
От Akim Demaille
Тема Re: Remove useless associativity/precedence from parsers
Дата
Msg-id 766895B5-236F-4588-961D-E004E9D21D56@lrde.epita.fr
обсуждение исходный текст
Ответ на Re: Remove useless associativity/precedence from parsers  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Remove useless associativity/precedence from parsers  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Remove useless associativity/precedence from parsers  (Andrew Dunstan <andrew.dunstan@2ndquadrant.com>)
Список 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 по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: VACUUM fails to parse 0 and 1 as boolean value
Следующее
От: Andres Freund
Дата:
Сообщение: Re: Create TOAST table only if AM needs