Jim Starkey wrote:

>The problem is with yacc. Tokens are declared in yacc by a %token
>declaration, such as
>
> %token PRIMARY
>
>Tokens are referenced directly in the grammar like the following:
>
> primary_constraint : PRIMARY KEY column_parens constraint_index_opt
> { $$ = MAKE_NODE (nod_primary, (int) e_pri_count, $3, $4); }
> ;
>
>Yacc/bison assigns an integer to each declared token that is used in the
>the generated parser. It also generates a file containing all tokens
>defined as macros of the keyword number:
>
> #define PRIMARY 401
>
>When lex sees the word "primary", it must recognize it as a token and
>return the lexeme 401 to yacc/bison. Unless it knows more about
>context, it can't know whether to return "primary" as a known token or a
>potential identifier string. An identifier string won't match the token
>"PRIMARY" and the token 401 won't match an indentifier string.
>
>The obvious trick is to make lex sensitive to the context, which is
>known in the industry as a hack. Too many hacks, and the structure
>crumbles.
>
>The solution is to ditch yacc/bison in favor of a more flexible parser
>that doesn't suffer with this disease. Writing a parse is a pretty
>trivial exercise once you get the hang of it. But it is boring,
>particularly with a very large grammar.
>
>

Ok, I see, thanks for the explanation. So it is possible, but it would
be a bit work... Fair enough. I don't think there would be much
advantage to going back on existing keywords (obviously), but it sure
would be nice if the future new features that get introduced didn't
introduce new keywords again... Changing column names in an existing
database, to get around a new keyword, is a lot of work!

Regards,
Jonathan Neve.