Related articles |
---|
[7 earlier articles] |
Oracle grammar ambiguities and conflicts mark.thiehatten@bibit.com (Mark Thiehatten) (2006-01-12) |
Re: Oracle grammar ambiguities and conflicts cfc@shell01.TheWorld.com (Chris F Clark) (2006-01-17) |
Re: Oracle grammar ambiguities and conflicts mattblackmon@hotmail.com (Matt Blackmon) (2006-01-17) |
Re: Oracle grammar ambiguities and conflicts david@tribble.com (David R Tribble) (2006-01-17) |
Re: Oracle grammar ambiguities and conflicts parsersinc@earthlink.net (SLK Parsers) (2006-01-19) |
Re: Oracle grammar ambiguities and conflicts parsersinc@earthlink.net (SLK Parsers) (2006-01-19) |
Re: Oracle grammar ambiguities and conflicts parsersinc@earthlink.net (SLK Parsers) (2006-01-20) |
From: | "SLK Parsers" <parsersinc@earthlink.net> |
Newsgroups: | comp.compilers |
Date: | 20 Jan 2006 16:13:02 -0500 |
Organization: | Parsers Inc. |
References: | 01-07-118 06-01-029 06-01-032 06-01-047 |
Keywords: | SQL, parse |
Posted-Date: | 20 Jan 2006 16:13:02 EST |
>> At a syntax error we check whether the current token is a keyword.
>> If an identifier token would be acceptable at this location then
>> we convert the keyword token into an identifier token and continue
>> parsing.
> If you can do it this way, I recommend you do.
> I'm going to add it to my bag-of-tricks.
> In other words, there is no downside to this technique.
Actually, I agree with your original assertion that the grammar solution is
best. Invoking error handling where there really is no error should be the
last resort.
Return to the
comp.compilers page.
Search the
comp.compilers archives again.