Overly conservative on reserved words?

Derby treats a number of tokens as reserved words that are over and 
above those defined by SQL. This poses a compatibility problem with some 
O/R mapping tools that do not surround these with delimiters when 
auto-mapping Java fields to the database.

These are:
ADD, AS, ASC, ASSERTION, BIT, CASCADE, COLLATION, CONNECTION, 
CONSTRAINTS, CONTINUE, DEFERRABLE, DEFERRED, DESC, DIAGNOSTICS, 
EXCEPTION, EXPLAIN, FIRST, FOUND, GETCURRENTCONNECTION, GO, GOTO, 
IMMEDIATE, ISOLATION, KEY, LAST, LONGINT, LTRIM, NVARCHAR, NEXT, OPTION, 
OUTPUT, PAD, PARTIAL, PRIOR, PRIVILEGES, PUBLIC, READ, RELATIVE, 
RESTRICT, RTRIM, SCHEMA, SPACE, SQLCODE, SUBSTR, TEMPORARY, VIEW, WORK, 
WRITE

It also does not reserve certain words that SQL does which may pose a 
compatibility issue in the future as users can use them as column names 
in the current version but may not be able to in later versions:

ABS, ARRAY, ASENSITIVE, ASYMMETRIC, ATOMIC, BIGINT, BINARY, BLOB, 
CALLED, CARDINALITY, CEIL, CEILING, CHAR_LENGTH, CHARACTER_LENGTH, CLOB, 
COALESCE, COLLECT, CONDITION, CORR, COVAR_POP, COVAR_SAMP, CROSS, CUBE, 
CUME_DIST, CURRENT_DEFAULT_TRANSPORT_GROUP_FOR_TYPE, CYCLE, DATE, DAY, 
DENSE_RANK, DEREF, DETERMINISTIC, DYNAMIC, EACH, ELEMENT, EVERY, EXP, 
EXTRACT, FILTER, FLOOR, FREE, FUSION, GROUPING, HOLD, INTERSECTION, 
INTERVAL, LANGUAGE, LARGE, LATERAL, LEADING, LN, LOCAL, LOCALTIME, 
LOCALTIMESTAMP, MEMBER, MERGE, METHOD, MOD, MODIFIES, MODULE, MONTH, 
MULTISET, NCLOB, NEW, NONE, NORMALIZE, OCTET_LENGTH, OVER, OVERLAY, 
PARAMETER, PARTITION, PERCENT_RANK, PERCENTILE_CONT, PERCENTILE_DISC, 
POSITION, POWER, PRECISION, PRIMARY, RANGE, RANK, READS, RECURSIVE, REF, 
REFERENCING, REGR_AVGX, REGR_AVGY, REGR_COUNT, REGR_INTERCEPT, REGR_R2, 
REGR_SLOPE, REGR_SXX, REGR_SXY, REGR_SYY, RELEASE, RESULT, RETURN, 
RETURNS, ROLLUP, ROW, ROW_NUMBER, SAVEPOINT, SCOPE, SEARCH, SENSITIVE, 
SIMILAR, SPECIFIC, SPECIFICTYPE, SQLEXCEPTION, SQLWARNING, SQRT, START, 
STATIC, STDDEV_POP, STDDEV_SAMP, SUBMULTISET, SYMMETRIC, SYSTEM, 
TABLESAMPLE, THEN, TIME, TIMESTAMP, TRAILING, TREAT, TRIGGER, TRIM, 
UESCAPE, UNNEST, VALUE, VAR_POP, VAR_SAMP, WHEN, WIDTH_BUCKET, WINDOW, 
WITHIN, WITHOUT

These are taken from the SQL-2003 spec part 2 on the basis that as the 
most recent spec it would have the most extensive list. Many of these 
pertain to features not likely to be in Derby any time soon (e.g. 
analytics, database objects).

We should be able to address the first group without user impact as we 
would increasing the available namespace. Assuming any lookahead issues 
in the parser can be resolved, can anyone see any issues doing this or 
object if I make these changes to Derby?

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.

From the ToDo list I could not see anything that looked liked we would 
need to reserve any of the words above any time soon. In the longer term:

* Functions and Datatypes
  We do not reserve these now, I assume because the parser does not
  require it. However, as the grammar gets more complex we may need to
  and users should be aware of it.

* SQL Procedure Language
  This seems very likely to need us to reserve additional words.
  However, I am not convinced we will ever actually need to implement it
  as I would assume most people would use Java as their procedure
  language.

* Savepoints
  Not on the todo list but a useful mechanism especially in conjunction
  with stored procedures/triggers. May just need SAVEPOINT

--
Jeremy