Re: Parser Cruft in gram.y

Поиск
Список
Период
Сортировка
От Peter Eisentraut
Тема Re: Parser Cruft in gram.y
Дата
Msg-id 50D31708.6090606@gmx.net
обсуждение исходный текст
Ответ на Re: Parser Cruft in gram.y  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Parser Cruft in gram.y
Список pgsql-hackers
On 12/18/12 5:10 PM, Robert Haas wrote:
> I can't help but suspect that the way we handle keywords today is
> monumentally inefficient.  The unreserved_keyword products, et al,
> just seem somehow badly wrong-headed.  We take the trouble to
> distinguish all of those cases so that we an turn around and not
> distinguish them.  I feel like there ought to be some way to use lexer
> states to handle this - if we're in a context where an unreserved
> keyword will be treated as an IDENT, then have the lexer return IDENT
> when it sees an unreserved keyword.  I might be wrong, but it seems
> like that would eliminate a whole lot of parser state transitions.
> However, even if I'm right, I have no idea how to implement it.  It
> just seems very wasteful that we have so many parser states that have
> no purpose other than (effectively) to convert an unreserved_keyword
> into an IDENT when the lexer could do the same thing much more cheaply
> given a bit more context.

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.

Of course, this is mostly speculation.



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

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: ThisTimeLineID in checkpointer and bgwriter processes
Следующее
От: Simon Riggs
Дата:
Сообщение: Re: Parser Cruft in gram.y