Appendices

Appendix A: CQL Keywords

CQL distinguishes between reserved and non-reserved keywords. Reserved keywords cannot be used as identifier, they are truly reserved for the language (but one can enclose a reserved keyword by double-quotes to use it as an identifier). Non-reserved keywords however only have a specific meaning in certain context but can used as identifier otherwise. The only raison d’être of these non-reserved keywords is convenience: some keyword are non-reserved when it was always easy for the parser to decide whether they were used as keywords or not.

Keyword Reserved?
ADD yes
AGGREGATE no
ALL no
ALLOW yes
ALTER yes
AND yes
APPLY yes
AS no
ASC yes
ASCII no
AUTHORIZE yes
BATCH yes
BEGIN yes
BIGINT no
BLOB no
BOOLEAN no
BY yes
CALLED no
CLUSTERING no
COLUMNFAMILY yes
COMPACT no
CONTAINS no
COUNT no
COUNTER no
CREATE yes
CUSTOM no
DATE no
DECIMAL no
DELETE yes
DESC yes
DESCRIBE yes
DISTINCT no
DOUBLE no
DROP yes
ENTRIES yes
EXECUTE yes
EXISTS no
FILTERING no
FINALFUNC no
FLOAT no
FROM yes
FROZEN no
FULL yes
FUNCTION no
FUNCTIONS no
GRANT yes
IF yes
IN yes
INDEX yes
INET no
INFINITY yes
INITCOND no
INPUT no
INSERT yes
INT no
INTO yes
JSON no
KEY no
KEYS no
KEYSPACE yes
KEYSPACES no
LANGUAGE no
LIMIT yes
LIST no
LOGIN no
MAP no
MODIFY yes
NAN yes
NOLOGIN no
NORECURSIVE yes
NOSUPERUSER no
NOT yes
NULL yes
OF yes
ON yes
OPTIONS no
OR yes
ORDER yes
PASSWORD no
PERMISSION no
PERMISSIONS no
PRIMARY yes
RENAME yes
REPLACE yes
RETURNS no
REVOKE yes
ROLE no
ROLES no
SCHEMA yes
SELECT yes
SET yes
SFUNC no
SMALLINT no
STATIC no
STORAGE no
STYPE no
SUPERUSER no
TABLE yes
TEXT no
TIME no
TIMESTAMP no
TIMEUUID no
TINYINT no
TO yes
TOKEN yes
TRIGGER no
TRUNCATE yes
TTL no
TUPLE no
TYPE no
UNLOGGED yes
UPDATE yes
USE yes
USER no
USERS no
USING yes
UUID no
VALUES no
VARCHAR no
VARINT no
WHERE yes
WITH yes
WRITETIME no

Appendix B: CQL Reserved Types

The following type names are not currently used by CQL, but are reserved for potential future use. User-defined types may not use reserved type names as their name.

type
bitstring
byte
complex
enum
interval
macaddr

Appendix C: Dropping Compact Storage

ALTER ... DROP COMPACT STORAGE statement makes Compact Tables CQL-compatible, exposing internal structure of Thrift/Compact Tables:

  • CQL-created Compact Tables that have no clustering columns, will expose an additional clustering column column1 with UTF8Type.
  • CQL-created Compact Tables that had no regular columns, will expose a regular column value with BytesType.
  • For CQL-Created Compact Tables, all columns originally defined as regular will be come static
  • CQL-created Compact Tables that have clustering but have no regular columns will have an empty value column (of EmptyType)
  • SuperColumn Tables (can only be created through Thrift) will expose a compact value map with an empty name.
  • Thrift-created Compact Tables will have types corresponding to their Thrift definition.
  • If a row was written while a table was still compact but it has no live cells due to later row or cell deletions, it may continue to be simply left out of query results, as is the normal behavior for compact tables. Rows written after a table is fully CQL-compatible, if they have no live cells but a live primary key, may be present in query results with null values.