Re: Parser Cruft in gram.y - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: Parser Cruft in gram.y
Date
Msg-id 50D31708.6090606@gmx.net
Whole thread Raw
In response to Re: Parser Cruft in gram.y  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Parser Cruft in gram.y  ("McDevitt, Charles" <Charles.McDevitt@emc.com>)
List 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 by date:

Previous
From: Andres Freund
Date:
Subject: Re: ThisTimeLineID in checkpointer and bgwriter processes
Next
From: Simon Riggs
Date:
Subject: Re: Parser Cruft in gram.y