Re: Overly conservative on reserved words?

Daniel John Debrunner wrote:
> Jeremy Boynes wrote:
>
>
> > Reserving additional words from the second group poses a bigger issue as
> > users' may have databases out there already using these words as
> > identifiers. The smoothest path is probably to give people an indication
> > of which words will need to be reserved at some point and hence should
> > be avoided; it is better for us to do this earlier than later.
>
>
> Actually having even keywords defined as reserved by the SQL Standard
> reserved in Derby has caused problems. I recently changed LOCAL not to
> be a reserved word as other databases do not enforce it. We probably
> need some set rules, but reserving because the SQL standard says so it
> not the approach taken by other products.

'The nice thing about standards is there are so many to choose from' :-)
Especially true with 4 versions of ISO SQL and N vendor-specific 
dialects. One of the issues users face is that the spec evolves and 
products implement newer versions, words that were not reserved before 
now need to be.

Ideally we would not need to reserve anything, giving users complete 
freedom on how they name their things; however, that would make the 
parser, lets say, challenging. Short of this ideal, I think we should 
compormise and only reserve words needed to resolve ambiguity in the 
parser; that lets users decide how much portability they need. To help 
them do that I think it's useful for us to indicate direction and what 
is likely to be reserved (SAVEPOINT) vs. what isn't (PERCENTILE_DISC).

Is it worth raising a warning on DDL operations that define objects that 
conflict with SQL's reservation list?

--
Jeremy