Re: Missing ColLabel tokens

> >> I suspect we're stuck on that for AS. However, TYPE is actually allowed
> >> as a ColId, via the 'generic' production, so in reality it's not
> >> reserved.
> > I think this generic production might be a mistake.
> It looks fairly weird to me too. Seems to me that we should get rid of
> token "generic", have ColId's first alternative be IDENT, add TYPE to
> ColId (or possibly TokenId), and have the Generic type production accept
> IDENT directly.
> Thomas, why'd you do it this way?

Hmm. I'm certain that I could not completely explain "why it is this
way" since this has all been accumulated in incremental changes over the
last 7 years ;) And I rarely feel that the current state is sufficiently
messed up to warrant larger cleanup changes -- though that has happened
at times -- so there may be some incremental additions which could be
replaced by some consolidations.

I'm not certain what specifically you are asking about wrt "why'd you do
it this way"...

It may be that "generic:" was originally there for symmetry with the
other "lowercase/uppercase" production pairs such as "character:" and
"Character:".

The CVS logs indicate that I allowed TYPE as a column name back in 1997.
The implication from the log (and my recollection) is that it would be
*nice* to have "type" allowed as a column name. And at the time, with
the existing productions, however it was done made sense for an
incremental change.

If we can clean up the grammar, great! But I'm a little worried that our
regression tests don't give sufficient coverage for some edge cases. For
example, I had found a few months ago that our CREATE TYPE productions
did not allow all SQL9x type names as arguments (if I remember the
example correctly)!

Anyway, cleanups are good, as long as they don't end up unnecessarily
restricting the set of allowed names in various contexts.

- Thomas