On Tue, Dec 18, 2012 at 5:24 PM, Peter Eisentraut <peter_e@gmx.net> wrote:
> 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.
>
> The problem would be the lookahead. You need to know the next token
> before you can decide what context the current one is in.
Yeah, that's why I don't know how to make it work. It feels like this
is partly artifact of the tool, though. I mean, suppose we haven't
read anything yet. Then, the next token can't be an IDENT, so if we
see an unreserved keyword, we know we're not going to convert it to an
IDENT. OTOH, if we've seen CREATE TABLE, the next token cannot be an
unreserved keyword that is intended as a keyword; it has to be
something that will reduce to ColId.
I guess the problem situation is where we can shift the keyword and
then use the following token to decide whether to reduce it to
ColId/type_function_name/ColLabel or use some other rule instead; the
CREATE INDEX CONCURRENTLY productions might be such a case.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
