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
