Re: Parser Cruft in gram.y

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Parser Cruft in gram.y
Дата
Msg-id 27479.1356047252@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Parser Cruft in gram.y  (Andres Freund <andres@2ndquadrant.com>)
Список pgsql-hackers
Andres Freund <andres@2ndquadrant.com> writes:
> On 2012-12-20 23:12:55 +0000, McDevitt, Charles wrote:
>>> Another way of attack along these lines might be to use the %glr-parser
>>> and then try to cut back on all those redundant rules that were put in
>>> to avoid conflicts.  The number of key words categories and such could
>>> perhaps also be reduced that way.

>> The GLR output from Bison is licensed under the GPL (unlike the LALR output).
>> So using Bison's GLR mode isn't an option.

> Thats not the case anymore:
> http://www.gnu.org/software/bison/manual/html_node/Conditions.html

This does mean that we'd have to specify a minimum bison version of 2.2
in order to be squeaky-clean license wise, if we went over to using the
GLR mode.  However, that would likely be a good idea anyway from a
technical standpoint --- the GLR mode may exist in ancient bison
versions, but who knows how bug-free it is.

Anyway, this is all merest speculation until somebody actually tries it
and sees if a performance gain is possible.  Having just re-read
the description of GLR mode, I wouldn't be surprised if any savings in
table size is squandered by its handling of ambiguous cases (ie, the
need to track and merge multiple parser states).
        regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Fujii Masao
Дата:
Сообщение: Re: ThisTimeLineID in checkpointer and bgwriter processes
Следующее
От: Thom Brown
Дата:
Сообщение: Re: Switching timeline over streaming replication