$Revision: 6753 $
Copyright 2009-2024 Fred Toussi. Permission is granted to distribute this document without any alteration under the terms of the HSQLDB license. Additional permission is granted to the HSQL Development Group to distribute this document with or without alterations under the terms of the HSQLDB license.
2024-06-01
Table of Contents
This chapter discusses features of HyperSQL in the context of the
SQL Standard. Strings enclosed in angle brackets (for example
<identifier>
) are SQL syntax elements.
The persistent elements of an SQL environment are database objects. The database consists of catalogs plus authorizations.
A catalog contains schemas, and schemas contain the objects that contain data or govern the data. Authorizations are user names.
Each catalog contains a special schema called INFORMATION_SCHEMA. This schema is read-only and contains some views and other schema objects. The views contain lists of all the database objects that exist within the catalog, plus all authorizations.
Each database object has a name. A name is an identifier and is unique within its name-space.
In HyperSQL, there is only one catalog per database. The name of the
catalog is PUBLIC. You can rename the catalog with the ALTER
CATALOG RENAME TO
statement. All schemas belong to this catalog.
The catalog name has no relation to the file name of the database.
Each database has also an internal "unique" name which is automatically generated when the database is created. This name is used for event logging. You can also change this unique name.
Schema objects are database objects that contain data or govern or perform operations on data. By definition, each schema object belongs to a specific schema.
Schema objects can be divided into groups according to their characteristics.
Some kinds of schema objects can exist independently from other schema object. Other kinds can exist only as an element of another schema object. These dependent objects are automatically destroyed when the parent object is dropped.
There are multiple name-spaces within each schema. Separate name-spaces exists for different kinds of schema object. Some name-spaces are shared between two similar kinds of schema objects.
There can be dependencies between various schema objects, as some kinds of schema objects can include references to other schema objects. These references can cross schema boundaries. Interdependence and cross referencing between schema objects is allowed in some circumstances and disallowed in some others.
Schema objects can be destroyed with the DROP statement. If dependent schema objects exist, a DROP statement will succeed only if it has a CASCADE clause. Dependent objects are also destroyed in most cases; but in some cases, such as dropping DOMAIN objects, the dependent objects are not destroyed, but modified to remove the dependency.
A new HyperSQL catalog contains an empty schema called PUBLIC. By default, this schema is the initial schema when a new session is started. Additional schemas can be defined. Schema objects can be defined and used in the PUBLIC schema, as well as any new schema that is created by the user. You can rename the PUBLIC schema.
HyperSQL allows all schemas to be dropped, except the schema that is the default initial schema for new sessions (by default, the PUBLIC schema). For this schema, a DROP SCHEMA ... CASCADE statement will succeed but will result in an empty schema, rather than no schema.
The statements for setting the initial schema for users are described in the Statements for Authorization and Access Control chapter.
The name of a schema object is an
<identifier>
. The name belongs to the
name-space for the particular kind of schema object. The name is unique
within its name-space. For example, each schema has a separate
name-space for TRIGGER objects.
In addition to the name-spaces in the schema. Each table has a name-space for the names of its columns.
Because a schema object is always in a schema and a schema always
in a catalog, it is possible, and sometimes necessary, to qualify the
name of the schema object that is being referenced in an SQL statement.
This is done by forming an <identifier chain>
.
In some contexts, only a simple <identifier>
can be used and the <identifier chain>
is
prohibited. While in some other contexts, the use of
<identifier chain>
is optional. An identifier
chain is formed by qualifying each object with the name of the object
that owns its name-space. Therefore, a column name is prefixed with a
table name, a table name is prefixed with a schema name, and a schema
name is prefixed with a catalog name. A fully qualified column name is
in the form <catalog name>.<schema name>.<table
name>.<column name>
, likewise, a fully qualified
sequence name is in the form <catalog name>.<schema
name>.<sequence name>
.
HyperSQL extends the SQL standard to allow renaming all database objects. The ALTER ... RENAME TO command has slightly different forms depending on the type of object. If an object is referenced in a VIEW or ROUTINE definition, it is not always possible to rename it.
A CHARACTER SET is the whole or a subset of the UNICODE character set.
A character set name can only be a <regular
identifier>
. There is a separate name-space for character
sets.
There are several predefined character sets. These character sets belong to INFORMATION_SCHEMA. However, when they are referenced in a statement, no schema prefix is necessary.
The following character sets, together with some others, have been specified by the SQL Standard:
SQL_CHARACTER, SQL_TEXT, SQL_IDENTIFIER
The SQL_CHARACTER consists of ASCII letters, digits and the symbols used in the SQL language itself. SQL_TEXT and SQL_IDENTIFIER are implementation defined. HyperSQL defines SQL_TEXT as the Unicode character set and SQL_IDENTIFIER as the Unicode character set minus the SQL language special characters.
SQL_TEXT consists of the full set of Unicode characters. These characters can be used in strings and clobs stored in the database. The character repertoire of HyperSQL is the UTF16 character set, which covers all possible character sets.
If a predefined character set is specified for a table column, then any string stored in the column must contain only characters from the specified character set. HyperSQL does not enforce the CHARACTER SET that is specified for a column and may accept any character string supported by SQL_TEXT.
A COLLATION is the method used for ordering character strings in ordered sets and to determine equivalence of two character strings.
The system collation is called SQL_TEXT. This collation sorts according to the Unicode code of the characters, UNICODE_SIMPLE. The system collation is always used for INFORMATION_SCHEMA tables.
The default database collation is the same as the system collation. You can change this default, either with a language collation, or with the SQL_TEXT_UCC. This collation is a case-insensitive form of the UNICODE_SIMPLE collation.
Collations for a large number of languages are supported by HyperSQL. These collations belong to INFORMATION_SCHEMA. However, when they are referenced in a statement, there is no need for a schema prefix.
A different collation than the default collation can be specified for each table column that is defined as CHAR or VARCHAR.
A collation can also be used in an ORDER BY clause.
A collation can be used in the GROUP BY clause.
CREATE TABLE t (id INTEGER PRIMARY KEY, name VARCHAR(20) COLLATE "English") SELECT * FROM t ORDER BY name COLLATE "French" SELECT COUNT(*), name FROM t GROUP BY name COLLATE "English 0"
In the examples above, the collation for the column is already
specified when it is defined. In the first SELECT statement, the column
is sorted using the French collation. In the second SELECT, the
"English 0"
collation is used in the GROUP BY clause.
This collation is case insensitive, so the same name with different uses
of upper and lower-case letters is considered the same and counted
together.
The supported collations are named according to the language. You
can see the list in the INFORMATION_SCHEMA.COLLATIONS view. You can use
just the name in double quotes for the default form of the collation. If
you add a strength between 0, 1, 2, 3, the case sensitivity and accent
sensitivity changes. The value 0 indicates least sensitivity to
differences. At this strength the collation is case-insensitive and
ignores differences between accented letters. At strength 1, differences
between accented letters are taken into account. At strength 2, both
case and accent are significant. Finally, 3 indicates additional
sensitivity to different punctuation. A second parameter can also be
used with values 0 or 1, to indicate how decomposition of accented
characters for comparison is handled for languages that support such
characters. See the Java and ICU (International Components for Unicode)
collation documentation for more details on these values. For example,
possible forms of the French collation are "French"
,
"French 0"
, "French 1"
, etc., and
"French 2 1"
, etc. When the collation is specified
without strength, it seems the system defaults to strength 2, which is
case and accent sensitive.
When a collation is not explicitly used in the CREATE TABLE statement for a column, then the database default collation is used for this column. If you change the database default collation afterwards, the new collation will be used.
With the older versions of HyperSQL the special type VARCHAR_IGNORECASE was used as the column type for case-insensitive comparison. Any column already defined as VARCHAR_IGNORECASE will be compared exactly as before. In version 2.3.0 and later, this form is represented by the addition of UCC after the collation name, for example "French UCC". You can still use the SET IGNORECASE TRUE statement in your session to force the UCC to be applied to the collation for the VARCHAR columns of new tables. UCC stands for Upper Case Comparison. Before comparing two strings, both are converted to uppercase using the current collation. This is exactly how VARCHAR_IGNORECASE worked.
It is recommended to use the default SQL_TEXT collation for your general CHAR or VARCHAR columns. For columns where a language collation is desirable, the choice should be made very carefully, because names that are very similar but only differ in the accents may be considered equal in searches.
When comparing two strings, HyperSQL 2.x pads the shorter string with spaces in order to compare two strings of equal length. You can change the default database collation with one that does not pad the string with spaces before comparison. This method of comparison was used in versions older than 2.0.
User defined collations can be created based on existing collations to control the space padding. These collations are part of the current schema.
See the COLLATE keyword and SET DATABASE COLLATION statement in the System Management chapter. The PAD SPACE or NO PAD clause is used to control padding.
Important | |
---|---|
If you change the default collation of a database when there are tables containing data with CHAR or VARCHAR columns that are part of an index, a primary key or a unique constraint, you must execute SHUTDOWN COMPACT or SHUTDOWN SCRIPT after the change. If you do not do this, your queries and other statements will show erratic behaviour and may result in unrecoverable errors. |
A distinct, user-defined TYPE is simply based on a built-in type. A distinct TYPE is used in table definitions and in CAST statements.
Distinct types share a name-space with domains.
A DOMAIN is a user-defined type, simply based on a built-in type. A DOMAIN can have constraints that limit the values that the DOMAIN can represent. A DOMAIN can be used in table definitions and in CAST statements.
Distinct types share a name-space with domains.
A SEQUENCE object produces INTEGER values in sequence. The SEQUENCE can be referenced in special contexts only within certain SQL statements. For each row where the object is referenced, its value is incremented.
There is a separate name-space for SEQUENCE objects.
IDENTITY columns are columns of tables which have an internal, unnamed SEQUENCE object. HyperSQL also supports IDENTITY columns that use a named, external, SEQUENCE object.
SEQUENCE objects and IDENTITY columns are supported fully according to the latest SQL Standard syntax.
Sequences
The SQL Standard syntax and usage is different from what is
supported by many existing database engines. Sequences are created with
the CREATE SEQUENCE
command and their current value
can be modified at any time with ALTER SEQUENCE
. The
next value for a sequence is retrieved with the NEXT VALUE FOR
<name>
expression. This expression can be used for
inserting and updating table rows.
Example 3.1. inserting the next sequence value into a table row
INSERT INTO mytable VALUES 2, 'John', NEXT VALUE FOR mysequence
You can also use it in select statements. For example, if you want to number the returned rows of a SELECT in sequential order, you can use:
Example 3.2. numbering returned rows of a SELECT in sequential order
SELECT NEXT VALUE FOR mysequence, col1, col2 FROM mytable WHERE ...
The semantics of sequences are exactly as defined by SQL:2023. If you use the same sequence twice in the same row in an INSERT statement, you will get the same value, as required by the Standard.
The correct way to use a sequence value is the NEXT VALUE FOR expression.
HyperSQL adds an extension to Standard SQL to return the last value returned by the NEXT VALUE FOR expression in the current session. After a statement containing NEXT VALUE FOR is executed, the value that was returned for NEXT VALUE FOR is available using the CURRENT VALUE FOR expression. In the example below, the NEXT VALUE FOR expression is used to insert a new row. The value that was returned by NEXT VALUE FOR is retrieved with the CURRENT VALUE FOR in the next insert statements to populate two new rows in a different table that has a parent child relationship with the first table. For example, if the value 15 was returned by the sequence, the same value 15 is inserted in the three rows.
Example 3.3. using the last value of a sequence
INSERT INTO mytable VALUES 2, 'John', NEXT VALUE FOR mysequence INSERT INTO childtable VALUES 4, CURRENT VALUE FOR mysequence INSERT INTO childtable VALUES 5, CURRENT VALUE FOR mysequence
The INFORMATION_SCHEMA.SEQUENCES table contains the next
value that will be returned from any of the defined sequences. The
SEQUENCE_NAME column contains the name and the NEXT_VALUE column
contains the next value to be returned. Note that this is only for
getting information and you should not use it for accessing the next
sequence value. When multiple sessions access the same sequence, the
value returned from this table by one session could be used by a
different session, causing a sequence value to be used twice
unintentionally.
Identity Auto-Increment Columns
Each table can contain a single auto-increment column, known as the IDENTITY column. An IDENTITY column is a SMALLINT, INTEGER, BIGINT, DECIMAL or NUMERIC column with its value generated by a sequence generator.
In HyperSQL 2.x, an IDENTITY column is not by default treated as the primary key for the table (as a result, multi-column primary keys are possible with an IDENTITY column present). Use the SQL standard syntax for declaration of the IDENTITY column.
The SQL standard syntax is used, which allows the initial value and other options to be specified.
<colname> [ INTEGER | BIGINT | DECIMAL | NUMERIC ]
GENERATED { BY DEFAULT | ALWAYS} AS IDENTITY [( <options>
)]
/* this table has no primary key */ CREATE TABLE vals (id INTEGER GENERATED BY DEFAULT AS IDENTITY, data VARBINARY(2000)) /* in this table id becomes primary key because the old syntax is used - avoid this syntax */ CREATE TABLE vals (id INTEGER IDENTITY, data VARBINARY(2000)) /* use the standard syntax and explicity declare a primary key identity column */ CREATE TABLE vals (id INTEGER GENERATED BY DEFAULT AS IDENTITY PRIMARY KEY, data VARBINARY(2000))
When you add a new row to such a table using an INSERT
INTO <tablename> ...
statement, you can use the DEFAULT
keyword for the IDENTITY column, which results in an auto-generated
value for the column.
The IDENTITY()
function returns the last value
inserted into any IDENTITY column by this session. Each session manages
this function call separately and is not affected by inserts in other
sessions. Use CALL IDENTITY()
as an SQL statement to
retrieve this value. If you want to use the value for a field in a child
table, you can use INSERT INTO <childtable> VALUES
(...,IDENTITY(),...);
. Both types of call to
IDENTITY()
must be made before any additional update or insert
statements are issued by the session.
In triggers and routines, the value returned by the
IDENTITY()
function is correct for the given context.
For example, if a call to a stored procedure inserts a row into a table,
causing a new identity value to be generated, a call to
IDENTITY()
inside the procedure will return the new
identity, but a call outside the procedure will return the last identity
value that was generated before a call was made to the procedure.
The last inserted IDENTITY value can also be retrieved via JDBC, by specifying the Statement or PreparedStatement object to return the generated value.
The next IDENTITY value to be used can be changed with the following statement. Note that this statement is not used in normal operation and is only for special purposes, for example resetting the identity generator:
ALTER TABLE <table name> ALTER COLUMN <column name> RESTART WITH <new value>;
For backward compatibility, support has been
retained for CREATE TABLE <tablename>(<colname>
IDENTITY, ...)
as a shortcut which defines the column both as
an IDENTITY column and a PRIMARY KEY column. Also, for backward
compatibility, it is possible to use NULL as the value of an IDENTITY
column in an INSERT statement and the value will be generated
automatically. You should avoid these compatibility features as they may
be removed from future versions of HyperSQL.
In the following example, the identity value for the first INSERT statement is generated automatically using the DEFAULT keyword. The second INSERT statement uses a call to the IDENTITY() function to populate a row in the child table with the generated identity value.
CREATE TABLE star (id INTEGER GENERATED BY DEFAULT AS IDENTITY PRIMARY KEY, firstname VARCHAR(20), lastname VARCHAR(20)) CREATE TABLE movies (starid INTEGER, movieid INTEGER PRIMARY KEY, title VARCHAR(40)) INSERT INTO star (id, firstname, lastname) VALUES (DEFAULT, 'Felix', 'the Cat') INSERT INTO movies (starid, movieid, title) VALUES (IDENTITY(), 10, 'Felix in Hollywood')
HyperSQL also supports IDENTITY columns that use an external, named SEQUENCE object. This feature is not part of the SQL Standard. The example below uses this type of IDENTITY. Note the use of CURRENT VALUE FOR seq here is multi-session safe. The returned value is the last value used by this session when the row was inserted into the star table. This value is available until the transaction is committed. After commit, NULL is returned by the CURRENT VALUE FOR expression until the SEQUENCE is used again.
CREATE SEQUENCE seq CREATE TABLE star (id INTEGER GENERATED BY DEFAULT AS SEQUENCE seq PRIMARY KEY, firstname VARCHAR(20), lastname VARCHAR(20)) CREATE TABLE movies (starid INTEGER, movieid INTEGER PRIMARY KEY, title VARCHAR(40)) -- the first insert uses the next value from the sequence seq INSERT INTO star (id, firstname, lastname) VALUES (DEFAULT, 'Felix', 'the Cat') -- the second insert uses CURRENT VALUE to insert the same auto-generated value into the other table INSERT INTO movies (starid, movieid, title) VALUES (CURRENT VALUE FOR seq, 10, 'Felix in Hollywood')
In the SQL environment, tables are the most essential components, as they hold all persistent data.
If TABLE is considered as metadata (without its actual data) it is called a relation in relational theory. It has one or more columns, with each column having a distinct name and a data type. A table usually has one or more constraints which limit the values that can potentially be stored in the TABLE. These constraints are discussed in the next section.
A single column of the table can be defined as IDENTITY. The values stored in this column are auto-generated and are based on an (unnamed) identity sequence, or optionally, a named SEQUENCE object. One or more other columns of the table can be defined as GENERATED by an expression that returns a value based on other columns of the same row.
A VIEW is similar to a TABLE but it does not permanently contain rows of data. A view is defined as a QUERY EXPRESSION, which is often a SELECT statement that references views and tables, but it can also consist of a TABLE CONSTRUCTOR that does not reference any tables or views.
A view has many uses:
Hide the structure and column names of tables. The view can represent one or more tables or views as a separate table. This can include aggregate data, such as sums and averages, from other tables.
Allow access to specific rows in a table. For example, records that were added since a given date.
Allow access to specific columns. For example, access to columns that contain non-confidential information. Note that this can also be achieved with the GRANT SELECT statement, using column-level privileges
A VIEW that returns the columns of a single ordinary TABLE is updatable if the query expression of the view is an updatable query expression as discussed in the Data Access and Change chapter. Some updatable views are insertable-into because the query expression is insertable-into. In these views, each column of the query expressions must be a column of the underlying table and those columns of the underlying table that are not in the view must have a default clause, or be an IDENTITY or GENERATED column. When rows of an updatable view are updated, or new rows are inserted, or rows are deleted, these changes are reflected in the base table. A VIEW definition may specify that the inserted or updated rows conform to the search condition of the view. This is done with the CHECK OPTION clause.
A view that is not updatable according to the above paragraph can be made updatable or insertable-into by adding INSTEAD OF triggers to the view. These triggers contain statements to use the submitted data to modify the contents of the underlying tables of the view separately. For example, a view that represents a SELECT statement that joins two tables can have an INSTEAD OF DELETE trigger with two DELETE statements, one for each table. Views that have an INSTEAD OF trigger are called TRIGGER INSERTABLE, TRIGGER UPDATABLE, etc., according to the triggers that have been defined.
Views share a name-space with tables.
A CONSTRAINT is a child schema object and can belong to a DOMAIN
or a TABLE. CONSTRAINT objects can be defined without specifying a name.
In this case the system generates a name for the new object beginning
with "SYS_". This default naming can be changed with the SET
DATABASE SQL SYS INDEX NAMES TRUE
statement, to use the
constraint name as the name of the index.
In a DOMAIN, CHECK constraints can be defined that limit the value represented by the DOMAIN. These constraints work exactly like a CHECK constraint on a single column of a table as described below.
In a TABLE, a constraint takes three basic forms.
CHECK
A CHECK constraint consists of a <search
condition>
that must not be false (can be unknown) for each
row of the table. The <search condition>
can
reference all the columns of the current row. HyperSQL does not support
the optional feature of the SQL Standard that allows a
<subquery>
referencing tables and views in the
database in a <search condition>
.
NOT NULL
A simple form of check constraint is the NOT NULL constraint, which applies to a single column.
UNIQUE
A UNIQUE constraint is based on an equality comparison of values of specific columns (taken together) of one row with the same values from each of the other rows. The result of the comparison must never be true (can be false or unknown). If a row of the table has NULL in any of the columns of the constraint, it conforms to the constraint. A unique constraint on multiple columns (c1, c2, c3, ..) means that in no two rows, the sets of values for the columns can be equal unless at least one of them is NULL. Each single column taken by itself can have repeat values in different rows. The following example satisfies a UNIQUE constraint on the two columns
Example 3.4. Column values which satisfy a 2-column UNIQUE constraint
1, | 2 |
2, | 1 |
2, | 2 |
NULL, | 1 |
NULL, | 1 |
1, | NULL |
NULL, | NULL |
NULL, | NULL |
If the SET DATABASE SQL UNIQUE NULLS FALSE has been set, then if not all the values set of columns are null, the not null values are compared and it is disallowed to insert identical rows that contain at least one not-null value.
PRIMARY KEY
A PRIMARY KEY constraint is equivalent to a UNIQUE constraint on one or more NOT NULL columns. Only one PRIMARY KEY can be defined in each table.
FOREIGN KEY
A FOREIGN key constraint is based on an equality comparison between values of specific columns (taken together) of each row with the values of the columns of a UNIQUE constraint on another table or the same table. The result of the comparison must never be false (can be unknown). A special form of FOREIGN KEY constraint, based on its CHECK clause, allows the result to be unknown only if the values for all columns are NULL. A FOREIGN key can be declared only if a UNIQUE constraint exists on the referenced columns.
Constraints share a name space with assertions.
An ASSERTION is a top-level schema object. It consists of a
<search condition>
that must not be false (can
be unknown). HyperSQL does not yet support assertions.
Assertions share a name-space with constraints
A TRIGGER is a child schema object that always belongs to a TABLE or a VIEW.
Each time a DELETE, UPDATE or INSERT is performed on the table or view, additional actions are taken by the triggers that have been declared on the table or view.
Triggers are discussed in detail in Triggers chapter.
There is a separate name space for triggers.
Routines are user-defined functions or procedures. The names and usage of functions and procedures are different. FUNCTION is a routine that can be referenced in many types of statements. PROCEDURE is a routine that can be referenced only in a CALL statement.
There is a separate name-space for routines.
Because of the possibility of overloading, each routine can have more than one name. The name of the routine is the same for all overloaded variants, but each variant has a specific name, different from all other routine names and specific names in the schema. The specific name can be specified in the routine definition statement. Otherwise it is assigned by the engine. The specific name is used only for schema manipulation statements, which need to reference a specific variant of the routine. For example, if a routine has two signatures, each signature has its own specific name. This allows the user to drop one of the signatures while keeping the other.
Routines are discussed in detail in the SQL-Invoked Routines chapter.
Indexes are an implementation-defined extension to the SQL Standard. HyperSQL has a dedicated name-space for indexes in each schema.
Synonyms are user-defined names that refer to other schema objects. Synonyms can be defined for TABLE, VIEW, SEQUENCE, PROCEDURE and FUNCTION names and used in SELECT, UPDATE, CALL, etc. statements. They cannot be used in DDL statements. Synonym are in schemas, but they are used without a schema qualifier. When used, a synonym is immediately translated to the target name and the target name is used in the actual statement. The access privileges to the target object are checked.
CREATE SYNONYM REG FOR OTHER_SCHEMA.REGISTRATION_DETAIL_TABLE SELECT R_ID, R_DATE FROM REG WHERE R_DATA > CURRENT_DATE - 3 DAY
A synonym cannot be the same as the name of any existing object in the schema.
Schemas and schema objects can be created, modified, and dropped. The SQL Standard defines a range of statements for this purpose. HyperSQL supports many additional statements, especially for changing the properties of existing schema objects.
These elements and statements are used for different types of object. They are described here, before the statements that can use them.
identifier
definition of identifier
<identifier> ::= <regular identifier> |
<delimited identifier> | <SQL language identifier>
<delimited identifier> ::= <double quote>
<character sequence> <double quote>
<regular identifier> ::= <special character
sequence>
<SQL language identifier> ::= <special
character sequence>
A <delimited identifier>
is a sequence of
characters enclosed with double-quote symbols. All characters are
allowed in the character sequence.
A <regular identifier>
is a special
sequence of characters. It consists of letters, digits, and the
underscore characters. It must begin with a letter. All the letters are
translated to their upper-case version.
The database setting, SET DATABASE SQL REGULAR NAMES
FALSE
can be used to relax the rules for regular identifier.
With this setting, an underscore character can appear at the start of
the regular identifier, and the dollar sign character can be used in the
identifier.
A <SQL language identifier>
is similar to
<regular identifier>
but the letters can range
only from A-Z in the ASCII character set. This type of identifier is
used for names of CHARACTER SET objects.
If the character sequence of a delimited identifier is the same as
an undelimited identifier, it represents the same identifier. For
example, "JOHN" is the same identifier as JOHN. In a
<regular identifier>
the case-normal form is
considered for comparison. This form consists of the upper-case
equivalent of all the letters. When a database object is created with
one of the CREATE statements or renamed with the ALTER statement, if the
name is enclosed in double quotes, the exact name is used as the
case-normal form. But if it is not enclosed in double quotes, the name
is converted to uppercase and this uppercase version is stored in the
database as the case-normal form.
The character sequence length of all identifiers must be between 1 and 128 characters.
A reserved word is one that is used by the SQL Standard for
special purposes. It is similar to a <regular
identifier>
but it cannot be used as an identifier for user
objects. If a reserved word is enclosed in double quote characters, it
becomes a quoted identifier and can be used for database objects.
Case sensitivity rules for identifiers can be described simply as follows:
all parts of SQL statements are converted to upper case before processing, except identifiers in double quotes and strings in single quotes
identifiers, both unquoted and double quoted, are then treated as case-sensitive
most database engines follow the same rule, except, in some respects, PostgreSQL, MySQL and MS SQLServer.
CASCADE or RESTRICT
drop behavior
<drop behavior> ::= CASCADE |
RESTRICT
The <drop behavior>
is a required element
of statements that drop a SCHEMA or a schema object. If
<drop behavior>
is not specified then
RESTRICT
is implicit. It determines the effect of the
statement if there are other objects in the catalog that reference the
SCHEMA or the schema object. If RESTRICT is specified, the statement
fails if there are referencing objects. If CASCADE is specified, all the
referencing objects are modified or dropped with cascading effect.
Whether a referencing object is modified or dropped, depends on the kind
of schema object that is dropped.
IF EXISTS
drop condition (HyperSQL)
<if exists clause> ::= IF
EXISTS
This clause is not part of the SQL standard and is a HyperSQL extension to some commands that drop objects (schemas, tables, views, sequences, and indexes). If it is specified, then the statement does not return an error if the drop statement is issued on a non-existent object.
IF NOT EXISTS
create condition (HyperSQL)
<if not exists clause> ::= IF NOT
EXISTS
This clause is not part of the SQL standard and is a HyperSQL extension to CREATE statements that create schemas, tables, views, sequences and indexes, as well as ALTER TABLE ... ADD CONSTRAINT and ADD COLUMN statements. If it is specified, then the statement does not return an error if the CREATE or ALTER statement is for an object name that already exists.
SPECIFIC
specific routine designator
<specific routine designator> ::= SPECIFIC
<routine type> <specific name>
<routine type> ::= ROUTINE | FUNCTION |
PROCEDURE
This clause is used in statements that need to specify one of the
multiple versions of an overloaded routine. The <specific
name>
is the one specified in the <routine
definition>
statement. The keyword
ROUTINE
can be used instead of either
FUNCTION
or PROCEDURE
.
RENAME
rename statement (HyperSQL)
<rename statement> ::= ALTER <object type>
<name> RENAME TO <new name>
<object type> ::= CATALOG | SCHEMA | DOMAIN |
TYPE | TABLE | CONSTRAINT | INDEX | ROUTINE | SPECIFIC
ROUTINE
<column rename statement> ::= ALTER TABLE
<table name> ALTER COLUMN <name> RENAME TO <new
name>
This statement is used to rename an existing object. It is not
part of the SQL Standard. The specified <name>
is the existing name, which can be qualified with a schema name, while
the <new name>
is the new name for the
object.
COMMENT
comment statement (HyperSQL)
<comment statement> ::= COMMENT ON { TABLE |
COLUMN | ROUTINE | SEQUENCE | TRIGGER} <name> IS <character
string literal>
Adds a comment to the object metadata, which can later be read
from an INFORMATION_SCHEMA view. This command is not part of the SQL
Standard. The strange syntax is due to compatibility with other database
engines that support the statement. The <name>
is the name of a table, view, column or routine. The name of the column
consists of dot-separated <table name> <period>
<column name>
. The name of the table, view or routine
can be a simple name. All names can be qualified with a schema name. If
there is already a comment on the object, the new comment will replace
it. Comments can be added to views and their columns using the TABLE
keyword.
The comments appear in the results returned by JDBC
DatabaseMetaData methods, getTables()
and
getColumns()
. The
INFORMATION_SCHEMA.SYSTEM_COMMENTS
view contains the
comments. You can query this view using the schema name, object name,
and column name to retrieve the comments.
CREATE SCHEMA
schema definition
The CREATE_SCHEMA
or DBA
role is required in order to create a schema. A schema can be created
with or without schema objects. Schema objects can always be added after
creating the schema, or existing ones can be dropped. Within the
<schema definition>
statement, all schema
object creation takes place inside the newly created schema. Therefore,
if a schema name is specified for the schema objects, the name must
match that of the new schema. In addition to statements for creating
schema objects, the statement can include instances of
<grant statement>
and <role
definition>
. This is a curious aspect of the SQL standard,
as these elements do not really belong to schema creation.
<schema definition> ::= CREATE SCHEMA <schema
name clause> [ <schema character set specification> ] [
<schema element>... ]
<schema name clause> ::= <schema name> |
AUTHORIZATION <authorization identifier> | <schema name>
AUTHORIZATION <authorization identifier>
If the name of the schema is specified simply as
<schema name>
, then the AUTHORIZATION is the
current user. Otherwise, the specified <authorization
identifier>
is used as the AUTHORIZATION for the schema. If
<schema name>
is omitted, then the name of the
schema is the same as the specified <authorization
identifier>
.
<schema element> ::= <table definition> |
<view definition> | <domain definition> | <character set
definition> | <collation definition> | <transliteration
definition> | <assertion definition> | <trigger
definition> | <user-defined type definition> | <user-defined
cast definition> | <user-defined ordering definition> |
<transform definition> | <schema routine> | <sequence
generator definition> | <grant statement> | <role
definition>
An example of the statement is given below. Note that a single semicolon appears at the end. There should be no semicolon between the statements:
CREATE SCHEMA ACCOUNTS AUTHORIZATION DBA CREATE TABLE AB(A INTEGER, ...) CREATE TABLE CD(C CHAR(10), ...) CREATE VIEW VI AS SELECT ... GRANT SELECT ON AB TO PUBLIC GRANT SELECT ON CD TO JOE;
It is not really necessary to create a schema and all its objects as one command. The schema can be created first, and its objects can be created one by one.
DROP SCHEMA
drop schema statement
<drop schema statement> ::= DROP SCHEMA [ IF
EXISTS ] <schema name> [ IF EXISTS ] <drop behavior>
This command destroys an existing schema. If <drop
behavior>
is RESTRICT
, the schema must
be empty, otherwise an error is raised. If CASCADE
is
specified as <drop behavior>
, then all the
objects contained in the schema are destroyed with a CASCADE
option.
CREATE TABLE
table definition
<table definition> ::= CREATE [ { <table
scope> | <table type> } ] TABLE [ IF NOT EXISTS ] <table
name> <table contents source> [ WITH SYSTEM VERSIONING ] [ ON
COMMIT { PRESERVE | DELETE } ROWS ]
<table scope> ::= { GLOBAL | LOCAL }
TEMPORARY
<table type> :: = MEMORY |
CACHED
<table contents source> ::= <table element
list> | <as subquery clause>
<table element list> ::= <left paren>
<table element> [ { <comma> <table element> }... ]
<right paren>
<table element> ::= <column definition> |
<table period definition> | <table constraint definition> |
<like clause>
like clause
A <like clause>
copies all column
definitions from another table into the newly created table. Its three
options indicate if the <default clause>
,
<identity column specification>
and
<generation clause>
associated with the column
definitions are copied or not. If an option is not specified, it
defaults to EXCLUDING
. The <generation
clause>
refers to columns that are generated by an
expression but not to identity columns. All NOT NULL constraints are
copied with the original columns, other constraints are not. The
<like clause>
can be used multiple times,
allowing the new table to have copies of the column definitions of one
or more other tables.
CREATE TABLE t (id INTEGER PRIMARY KEY, LIKE atable INCLUDING DEFAULTS EXCLUDING IDENTITY)
<like clause> ::= LIKE <table name> [
<like options> ]
<like options> ::= <like
option>...
<like option> ::= <identity option> |
<column default option> | <generation
option>
<identity option> ::= INCLUDING IDENTITY |
EXCLUDING IDENTITY
<column default option> ::= INCLUDING DEFAULTS |
EXCLUDING DEFAULTS
<generation option> ::= INCLUDING GENERATED |
EXCLUDING GENERATED
as subquery clause
<as subquery clause> ::= [ <left paren>
<column name list> <right paren> ] AS <table subquery>
{ WITH NO DATA | WITH DATA }
An <as subquery clause>
used in table
definition creates a table based on a <table
subquery>
. This kind of table definition is similar to a
view definition. It can include new column names to override the column
names specified in the subquery. If WITH DATA
is
specified, then the new table will contain the rows of data returned by
the <table subquery>
.
CREATE TABLE t (a, b, c) AS (SELECT * FROM atable) WITH DATA
column definition
A column definition consists of a <column
name>
and in most cases a <data
type>
or <domain name>
as minimum.
The other elements of <column definition>
are
optional. Each <column name>
in a table is
unique.
<column definition> ::= <column name> [
<data type or domain name> ] [ <default clause> |
<identity column specification> | <identity column sequence
specification> | <generation clause> ] [ <update clause>
] [ <column constraint definition>... ] [ <collate clause>
]
<data type or domain name> ::= <data type>
| <domain name>
<column constraint definition> ::= [
<constraint name definition> ] <column constraint> [
<constraint characteristics> ]
<column constraint> ::= NOT NULL | <unique
specification> | <references specification> | <check
constraint definition>
A <column constraint definition>
is a
shortcut for a <table constraint definition>
. A
constraint that is defined in this way is automatically turned into a
table constraint. A name is automatically generated for the constraint
and assigned to it.
If a <collate clause>
is specified,
then a UNIQUE or PRIMARY KEY constraint or an INDEX on the column will
use the specified collation. Otherwise the default collation for the
database is used.
GENERATED
generated columns
The value of a column can be auto-generated in two ways.
One way is specific to columns of integral types (INTEGER, BIGINT, etc.) and associates a sequence generator with the column. When a new row is inserted into the table, the value of the column is generated as the next available value in the sequence.
The SQL Standard supports the use of unnamed sequences with the IDENTITY keyword. In addition, HyperSQL supports the use of a named SEQUENCE object, which must be in the same schema as the table.
<identity column specification> ::= GENERATED {
ALWAYS | BY DEFAULT } AS IDENTITY [ <left paren> <common
sequence generator options> <right paren> ]
<identity column sequence specification ::=
GENERATED BY DEFAULT AS SEQUENCE <sequence name>
The <identity column specification>
or
<identity column sequence specification>
can be
specified for only a single column of the table.
The <identity column specification>
is
used for columns which represent values based on an unnamed sequence
generator. It is possible to insert a row into the table without
specifying a value for the column. The value is then generated by the
sequence generators according to its rules. An identity column may or
may not be the primary key. Example below:
CREATE TABLE t1 (id INTEGER GENERATED ALWAYS AS IDENTITY(START WITH 100), name VARCHAR(20) PRIMARY KEY) CREATE TABLE t2 (id INTEGER GENERATED BY DEFAULT AS IDENTITY(START WITH 1) PRIMARY KEY, name VARCHAR(20))
The <identity column sequence
specification>
is used when the column values are based on
a named SEQUENCE object (which must already exist). Example
below:
CREATE TABLE t3 (id INTEGER GENERATED BY DEFAULT AS SEQUENCE seq, name VARCHAR(20) PRIMARY KEY)
Inserting rows is done in the same way for a named or unnamed sequence generator. In both cases, if no value is specified to be inserted, or the DEFAULT keyword is used for the column, the value is generated by the sequence generator. If a value is specified, this value is used if the column definition has the BY DEFAULT specification. If the column definition has the ALWAYS specification, a value can be specified but the OVERRIDING SYSTEM VALUES must be specified in the INSERT statement. In the example below, the OVERRIDING clause is required because a user value is provided.
INSERT INTO t1 (id, name) OVERRIDING SYSTEM VALUE VALUES ( 14, 'Test Value')
The alternative form of the OVERRIDING clause is OVERRIDING USER VALUES. This is not used much as it is always possible to avoid it. When this option is specified, the database engine ignores the value provided by user and inserts the generated sequence value instead.
The other way in which the column value is auto-generated is by using the values of other columns in the same row. This method is often used to create an index on a value that is derived from other column values.
<generation clause> ::= GENERATED ALWAYS AS
<generation expression>
<generation expression> ::= <left paren>
<value expression> <right paren>
The <generation clause>
is used for
special columns which represent values based on the values held in other
columns in the same row. The <value expression>
must reference only other, non-generated, columns of the table in the
same row. Any function used in the expression must be deterministic and
must not access SQL-data. No <query expression>
is allowed. When <generation clause>
is used,
<data type>
must be specified.
A generated column can be part of a foreign key or unique constraints or a column of an index. This capability is the main reason for using generated columns. A generated column may contain a formula that computes a value based on the values of other columns. Fast searches of the computed value can be performed when an index is declared on the generated column. Or the computed values can be declared to be unique, using a UNIQUE constraint on the table. The computed column cannot be overridden by user supplied values. When a row is updated and the column values change, the generated columns are computed with the new values.
When a row is inserted into a table, or an existing row is updated, no value except DEFAULT can be specified for a generated column. In the example below, data is inserted into the non-generated columns and the generated column will contain 'Felix the Cat' or 'Pink Panther'.
CREATE TABLE t (id INTEGER PRIMARY KEY, firstname VARCHAR(20), lastname VARCHAR(20), fullname VARCHAR(40) GENERATED ALWAYS AS (firstname || ' ' || lastname)) INSERT INTO t (id, firstname, lastname) VALUES (1, 'Felix', 'the Cat') INSERT INTO t (id, firstname, lastname, fullname) VALUES (2, 'Pink', 'Panther', DEFAULT)
DEFAULT
default clause
A default clause can be used if GENERATED is not specified. If a
column has a <default clause>
then it is
possible to insert a row into the table without specifying a value for
the column.
<default clause> ::= DEFAULT <default
option>
<default option> ::= <literal> |
<datetime value function> | USER | CURRENT_USER | CURRENT_ROLE |
SESSION_USER | SYSTEM_USER | CURRENT_CATALOG | CURRENT_SCHEMA |
CURRENT_PATH | NULL
The type of the <default option>
must
match the type of the column.
In PGS (PostgreSQL) compatibility mode, a NEXTVAL function can be used. Also, in MSS compatibility mode, the default value can be enclosed in parentheses.
ON UPDATE
on update clause
If a column has a <on update clause>
then
every time an UPDATE or MERGE statement updates the values of the other
columns of the row, the value in this column is updated to the
CURRENT_TIMESTAMP. If the UPDATE statement explicitly updates this
column, then the explicit value is used instead of CURRENT
TIMESTAMP.
<on update clause> ::= ON UPDATE
CURRENT_TIMESTAMP
The type of the column must be TIMESTAMP or TIMESTAMP WITH TIME ZONE.
This feature is not part of the SQL Standard and is similar to MySQL's ON UPDATE clause.
CONSTRAINT
constraint name and characteristics
<constraint name definition> ::= CONSTRAINT
<constraint name>
<constraint characteristics> ::= <constraint
check time> [ [ NOT ] DEFERRABLE [ <constraint check time> ]
]
<constraint check time> ::= INITIALLY DEFERRED |
INITIALLY IMMEDIATE
Specify the name of a constraint and its characteristics. By
default, the constraint is NOT DEFERRABLE
and
INITIALLY IMMEDIATE
. This means the constraint is
enforced as soon as a data change statement is executed. If
INITIALLY DEFERRED
is specified, then the constraint
is enforced when the session commits. The characteristics must be
compatible. The constraint check time can be changed temporarily for an
SQL session. HyperSQL does not support deferring constraint enforcement.
This feature of the SQL Standard has been criticised because it allows a
session to read uncommitted data that violates database integrity
constraints but has not yet been checked.
CONSTRAINT
table constraint definition
<table constraint definition> ::= [
<constraint name definition> ] <table constraint> [
<constraint characteristics> ]
<table constraint> ::= <unique constraint
definition> | <referential constraint definition> | <check
constraint definition>
Three kinds of constraint can be defined on a table: UNIQUE (including PRIMARY KEY), FOREIGN KEY and CHECK. Each kind has its own rules to limit the values that can be specified for different columns in each row of the table.
UNIQUE
unique constraint definition
<unique constraint definition> ::= <unique
specification> <left paren> <unique column list>
<right paren> | UNIQUE ( VALUE )
<unique specification> ::= UNIQUE | PRIMARY
KEY
<unique column list> ::= <column name
list>
A unique constraint is specified on a single column or on multiple columns. On each set of columns taken together, only one UNIQUE constraint can be specified. Each column of a PRIMARY KEY constraint has an implicit NOT NULL constraint.
If UNIQUE( VALUE )
is specified, the
constraint created on all columns of the table.
FOREIGN KEY
referential constraint definition
<referential constraint definition> ::= FOREIGN
KEY <left paren> <referencing columns> <right paren>
<references specification>
<references specification> ::= REFERENCES
<referenced table and columns> [ MATCH <match type> ] [
<referential triggered action> ]
<match type> ::= FULL | PARTIAL |
SIMPLE
<referencing columns> ::= <reference column
list>
<referenced table and columns> ::= <table
name> [ <left paren> <reference column list> <right
paren> ]
<reference column list> ::= <column name
list>
<referential triggered action> ::= <update
rule> [ <delete rule> ] | <delete rule> [ <update
rule> ]
<update rule> ::= ON UPDATE <referential
action>
<delete rule> ::= ON DELETE <referential
action>
<referential action> ::= CASCADE | SET NULL |
SET DEFAULT | RESTRICT | NO ACTION
A referential constraint allows links to be established between
the rows of two tables. The specified list of <referencing
columns>
corresponds one by one to the columns of the
specified list of <referenced columns>
in
another table (or sometimes in the same table). For each row in the
table, a row must exist in the referenced table with equivalent values
in the two column lists. There must exist a single unique constraint in
the referenced table on all the <referenced
columns>
.
The [ MATCH match type ]
clause is optional and
has an effect only on multi-column foreign keys and only on rows
containing at least a NULL in one of the <referencing
columns>
. If the clause is not specified, MATCH SIMPLE is
the default. If MATCH SIMPLE
is specified, then any
NULL means the row can exist (without a corresponding row in the
referenced table). If MATCH FULL
is specified then
either all the column values must be NULL or none of them.
MATCH PARTIAL
allows any NULL but the non NULL values
must match those of a row in the referenced table. HyperSQL does not
support MATCH PARTIAL
.
Referential actions are specified with ON UPDATE and ON DELETE clauses. These actions take place when a row in the referenced table (the parent table) has referencing rows in the referencing table and it is deleted or modified with any SQL statement. The default is NO ACTION. This means the SQL statement that causes the DELETE or UPDATE is terminated with an exception. The RESTRICT option is similar and works exactly the same without deferrable constraints (which are not allowed by HyperSQL). The other three options, CASCADE, SET NULL and SET DEFAULT all allow the DELETE or UPDATE statement to complete. With DELETE statements the CASCADE option results in the referencing rows to be deleted. With UPDATE statements, the changes to the values of the referenced columns are copied to the referencing rows. With both DELETE or UPDATE statement, the SET NULL option results in the columns of the referencing rows to be set to NULL. Similarly, the SET DEFAULT option results in the columns of the referencing rows to be set to their default values.
CHECK
check constraint definition
<check constraint definition> ::= CHECK <left
paren> <search condition> <right
paren>
A CHECK constraint can exist for a TABLE or for a DOMAIN. The
<search condition>
evaluates to an SQL BOOLEAN
value for each row of the table. Within the <search
condition>
all columns of the table row can be referenced.
For all rows of the table, the <search
condition>
evaluates to TRUE or UNKNOWN. When a new row is
inserted, or an existing row is updated, the <search
condition>
is evaluated and if it is FALSE, the insert or
update fails.
A CHECK constraint for a DOMAIN is similar. In its
<search condition>
, the term VALUE is used to
represents the value to which the DOMAIN applies.
CREATE TABLE t (a VARCHAR(20) CHECK (a IS NOT NULL AND CHARACTER_LENGTH(a) > 2))
The search condition of a CHECK constraint cannot contain any function that is not deterministic. A check constraint is a data integrity constraint; therefore it must hold with respect to the rest of the data in the database. It cannot use values that are temporal or ephemeral. For example, CURRENT_USER is a function that returns different values depending on who is using the database, or CURRENT_DATE changes day-to-day. Some temporal expressions are retrospectively deterministic and are allowed in check constraints. For example, (CHECK VALUE < CURRENT_DATE) is valid, because CURRENT_DATE will not move backwards in time, but (CHECK VALUE > CURRENT_DATE) is not acceptable.
If you want to enforce the condition that a date value that is inserted into the database belongs to the future (at the time of insertion), or any similar constraint, then use a TRIGGER with the desired condition.
DROP TABLE
drop table statement
<drop table statement> ::= DROP TABLE [ IF
EXISTS ] <table name> [ IF EXISTS ] <drop
behavior>
Destroy a table. The default drop behaviour is RESTRICT and will
cause the statement to fail if there is any view, routine or foreign key
constraint that references the table. If <drop
behavior>
is CASCADE
, it causes all
schema objects that reference the table to drop. Referencing views are
dropped. In the case of foreign key constraints that reference the
table, the constraint is dropped, rather than the TABLE that contains
it.
System-versioned tables are tables that contain a SYSTEM_TIME period consisting of pair of columns defined as auto-generated TIMESTAMP WITH TIME ZONE, together with the SYSTEM VERSIONING clause.
The basic component is the SYSTEM_TIME period. For each row currently in the table, the start timestamp column, designated as ROW START, contains the UTC timestamp of the transaction of the INSERT or UPDATE statement that last modified the row. The end timestamp column, designated as ROW END, contains a timestamp in the distant future (end of epoch) that indicates the expiration date of the row. HyperSQL uses DATE '10000-01-01' as the expiration timestamp. A table can have the SYSTEM_TIME period without system versioning.
When WITH SYSTEM VERSIONING is used in table definition, any DELETE or UPDATE is performed as usual. But the deleted rows, and the old versions of the updated rows, are kept in the table with the expiration timestamp changed to the UTC CURRENT_TIMESTAMP at the start of the transaction that contains the UPDATE or DELETE. For example, a row that is updated twice has two old versions kept in the table as well as the current version.
The history rows cannot be modified. Any DELETE or UPDATE
statement only sees the current version of each row of the table and
modifies them. SELECT statements also see the current version of the
rows, unless the table reference in the SELECT statement is followed by
FOR SYSTEM_TIME AS OF <timestamp>
or
FOR SYSTEM_TIME FROM <start timestamp> TO <end
timestamp>
or FOR SYSTEM_TIME BETWEEN <start
timestamp> AND <end timestamp>
.
In a CREATE TABLE statement, the two period columns must be defined as follows:
<period begin column name> <timestamp data
type> GENERATED ALWAYS AS ROW START
<period end column name> <timestamp data
type> GENERATED ALWAYS AS ROW END
The <table period definition>
references
the period column, in a format similar to a UNIQUE constraint.
<table period definition> ::= PERIOD FOR
SYSTEM_TIME <left paren> <period begin column name>
<comma> <period end column name> <right
paren>
The timestamp type actually used by the system is always TIMESTAMP(6) WITH TIME ZONE, regardless of the type specified by the user.
An existing table can be converted to a system-versioned table. Two statement executions are needed. First, the ALTER TABLE statement to create the SYSTEM_TIME period and its columns must be executed, followed by the ALTER TABLE statement to add SYSTEM VERSIONING.
Conversely, system versioning can be removed from a table. The system period can be dropped after dropping system versioning.
It is not allowed to change the structure of a system-versioned table by adding or removing columns.
See the ALTER TABLE statements in this chapter.
Table settings statements change the attributes of tables. These attributes are specific to HyperSQL and are not part of the SQL Standard.
SET TABLE CLUSTERED
set table clustered property
<set table clustered statement> ::= SET TABLE
<table name> CLUSTERED ON <left paren> <column name
list> <right paren>
Set the row clustering property of a table. The <column name list> is a list of column names that must correspond to the columns of an existing PRIMARY KEY, UNIQUE or FOREIGN KEY index, or to the columns of a user defined index. This statement is only valid for CACHED or TEXT tables.
Tables rows are stored in the database files as they are created, sometimes at the end of the file, sometimes in the middle of the file. After a CHECKPOINT DEFRAG or SHUTDOWN COMPACT, the rows are reordered according to the primary key of the table, or if there is no primary key, in no particular order.
When several consecutive rows of a table are retrieved during query execution it is more efficient to retrieve rows that are stored adjacent to one another. After executing this command, nothing changes until a CHECKPOINT DEFRAG or SHUTDOWN COMPACT or SHUTDOWN SCRIPT is performed. After these operations, the rows are stored in the specified clustered order. The property is stored in the database and applies to all future reordering of rows. Note that if extensive inserts or updates are performed on the tables, the rows will get out of order until the next reordering.
SET TABLE TYPE
set table type
<set table type statement> ::= SET TABLE
<table name> TYPE { MEMORY | CACHED }
Changes the storage type of an existing table between CACHED and MEMORY types.
Only a user with the DBA role can execute this statement.
SET TABLE writability
set table write property
<set table read only statement> ::= SET TABLE
<table name> { READ ONLY | READ WRITE }
Set the writability property of a table. Tables are writable by
default. This statement can be used to change the property between
READ ONLY
and READ WRITE
. This is
a feature of HyperSQL.
SET TABLE SOURCE
set table source statement
<set table source statement> ::= SET TABLE
<table name> SOURCE <file and options>
[DESC]
<file and options>::= <doublequote>
<file path> [<semicolon> <property>...]
<doublequote>
Set the text source for a text table. This statement cannot be used for tables that are not defined as TEXT TABLE.
Supported Properties
quoted = { true | false } |
default is true. If false, treats double quotes as normal characters |
all_quoted = { true | false } |
default is false. If true, adds double quotes around all fields. |
encoding = <encoding name> |
character encoding for text and character fields, for example, encoding=UTF-8. UTF-16 or other encodings can also be used. |
ignore_first = { true | false } |
default is false. If true ignores the first line of the file |
cache_rows= <numeric value> |
rows of the text file in the cache. Default is 1000 rows |
cache_size = <numeric value>r |
total size of the row in the cache. Default is 100 KB. |
cache_scale= <numeric value> and cache_size_scale = <numeric value> |
deprecated properties, replaced by cached_rows and cache_size properties above. |
fs = <unquoted character> |
field separator |
vs = <unquoted character> |
varchar separator |
qc = <unquoted character> |
quote character |
Special indicators for HyperSQL Text Table separators
\semi |
semicolon |
\quote |
quote |
\space |
space character |
\apos |
apostrophe |
\n |
newline - Used as an end anchor (like $ in regular expressions) |
\r |
carriage return |
\t |
tab |
\\ |
backslash |
\u#### |
a Unicode character specified in hexadecimal |
In the example below, the text source of the table is set to "myfile", the field separator to the pipe symbol, and the varchar separator to the tilde symbol.
SET TABLE mytable SOURCE 'myfile;fs=|;vs=.;vs=~'
Only a user with the DBA role can execute this statement.
SET TABLE SOURCE HEADER
set table source header statement
<set table source header statement> ::= SET
TABLE <table name> SOURCE HEADER <header
string>
Set the header for the text source for a text table. If this
command is used, the <header string>
is used as
the first line of the source file of the text table. This line is not
part of the table data. Only a user with the DBA role can execute this
statement.
SET TABLE SOURCE on-off
set table source on-off statement
<set table source on-off statement> ::= SET
TABLE <table name> SOURCE { ON | OFF }
Attach or detach a text table from its text source. This command does not change the properties or the name of the file that is the source of a text table. When OFF is specified, the command detaches the table from its source and closes the file for the source. In this state, it is not possible to read or write to the table. This allows the user to replace the file with a different file, or delete it. When ON is specified, the source file is read. Only a user with the DBA role can execute this statement.
Table manipulation statements modify the objects such as columns and constraints. Some of these statements are defined by the SQL Standard. Others are HyperSQL extensions.
ALTER TABLE
alter table statement
<alter table statement> ::= ALTER TABLE
<table name> <alter table action>
<alter table action> ::= <add column
definition> | <alter column definition> | <drop column
definition> | <add table constraint definition> | <drop
table constraint definition> | <add table period definition> |
<drop table period definition> | <add system versioning
clause> | <drop system versioning clause>
Change the definition of a table. Specific types of this statement are covered below.
ADD COLUMN
add column definition
<add column definition> ::= ADD [ COLUMN ] [IF
NOT EXISTS] <column definition> [ BEFORE <other column name>
]
Add a column to an existing table. The <column
definition>
is specified the same way as it is used in
<table definition>
. HyperSQL allows the use of
[ BEFORE <other column name> ]
to specify at
which position the new column is added to the table.
If the table contains rows, the new column must have a
<default clause>
or use one of the forms of
GENERATED. The column values for each row is then filled with the result
of the <default clause>
or the generated
value.
DROP COLUMN
drop column definition
<drop column definition> ::= DROP [ COLUMN ]
<column name> <drop behavior>
Destroy a column of a base table. The <drop
behavior>
is either RESTRICT
or
CASCADE
. If the column is referenced in a table
constraint that references other columns as well as this column, or if
the column is referenced in a VIEW, or the column is referenced in a
TRIGGER, then the statement will fail if RESTRICT
is
specified. If CASCADE
is specified, then any
CONSTRAINT, VIEW or TRIGGER object that references the column is dropped
with a cascading effect.
ADD CONSTRAINT
add table constraint definition
<add table constraint definition> ::= ADD
<table constraint definition>
Add a constraint to a table. The existing rows of the table must conform to the added constraint, otherwise the statement will not succeed.
DROP CONSTRAINT
drop table constraint definition
<drop table constraint definition> ::= DROP
CONSTRAINT <constraint name> <drop
behavior>
Destroy a constraint on a table. The <drop
behavior>
has an effect only on UNIQUE and PRIMARY KEY
constraints. If such a constraint is referenced by a FOREIGN KEY
constraint, the FOREIGN KEY constraint will be dropped if
CASCADE
is specified. If the columns of such a
constraint are used in a GROUP BY clause in the query expression of a
VIEW or another kind of schema object, and a functional dependency
relationship exists between these columns and the other columns in that
query expression, then the VIEW or other schema object will be dropped
when CASCADE
is specified.
ADD SYSTEM PERIOD
add system period definition
<add table system period definition> ::= ADD
PERIOD FOR SYSTEM_TIME <left paren> <period begin column
name> <comma> <period end column name> <right
paren> ADD COLUMN <period begin column name> <timestamp data
type> GENERATED ALWAYS AS ROW START ADD COLUMN <period end column
name> <timestamp data type> GENERATED ALWAYS AS ROW
END
Add the system period definition and columns to a table. The long statement must be entered in full. The existing rows of the table are marked as created at the current timestamp with end-of-epoch expiration timestamp.
ALTER TABLE t ADD PERIOD FOR SYSTEM_TIME(rs, re) ADD COLUMN rs TIMESTAMP GENERATED ALWAYS AS ROW START ADD COLUMN re TIMESTAMP GENERATED ALWAYS AS ROW END
DROP SYSTEM PERIOD
drop system period definition
<drop table system period definition> ::= DROP
PERIOD FOR SYSTEM_TIME <drop behavior>
Drop the system period definition and columns of a table. The
<drop behavior>
is either
RESTRICT
or CASCADE
. If the system
period or its columns have been referenced in other database object such
as VIEW or ROUTINE, then the statement will fail if
RESTRICT
is specified. If CASCADE
is specified, then any such VIEW or other database object that
references the period or its columns is dropped with a cascading
effect
ADD SYSTEM VERSIONING
add system versioning clause
<add system versioning clause> ::= ADD SYSTEM
VERSIONING
Add system versioning to a table that already has a SYSTEM_TIME period definition and columns.
ALTER TABLE t ADD SYSTEM VERSIONING
DROP SYSTEM VERSIONING
drop system versioning clause
<drop table system period definition> ::= DROP
SYSTEM VERSIONING
Drop system versioning of a table. The <drop
behavior>
is either RESTRICT
or
CASCADE
. If system versioning has been referenced in
other database object such as VIEW or ROUTINE, then the statement will
fail if RESTRICT
is specified. If
CASCADE
is specified, then any such VIEW or other
database object that references system versioning is dropped with a
cascading effect A references to system versioning consists of the FOR
SYSTEM_TIME clause in a SELECT statement. With the successful execution
of this statement, all the history rows in the table are deleted and
only the current versions of rows survive. The period for SYSTEM_TIME,
and its columns, survive after dropping versioning.
ALTER COLUMN
alter column definition
<alter column definition> ::= ALTER [ COLUMN ]
<column name> <alter column action>
<alter column action> ::= <set column default
clause> | <drop column default clause> | <alter column data
type clause> | <alter identity column specification> |
<alter column nullability> | <alter column name> | <add
column identity specification> | <drop column identity
specification>
Change a column and its definition. Specific types of this statement are covered below. See also the RENAME statement above.
SET DEFAULT
set column default clause
<set column default clause> ::= SET <default
clause>
Set the default clause for a column. This can be used if the column is not defined as GENERATED.
DROP DEFAULT
drop column default clause
<drop column default clause> ::= DROP
DEFAULT
Drop the default clause from a column.
SET DATA TYPE
alter column data type clause
<alter column data type clause> ::= SET DATA
TYPE <data type>
Change the declared type of a column. The latest SQL Standard allows only changes to type properties such as maximum length, precision, or scale, and only changes that cause the property to enlarge. HyperSQL allows changing the type if all the existing values can be cast into the new type without string truncation or loss of significant digits.
alter column add identity generator or sequence
alter column add identity generator or sequence
<add column identity generator> ::= <identity
column specification>
<add column sequence generator> ::= <identity
column sequence specification>
Adds an identity specification or a sequence to the column. The type of the column must be an integral type and the existing values must not include nulls. This option is specific to HyperSQL
ALTER TABLE mytable ALTER COLUMN id GENERATED ALWAYS AS IDENTITY (START WITH 20000)
ALTER TABLE mytable ALTER COLUMN id GENERATED BY DEFAULT AS SEQUENCE seq
alter column identity generator
alter identity column specification
<alter identity column specification> ::=
<alter identity column option>...
<alter identity column option> ::= <alter
sequence generator restart option> | SET <basic sequence generator
option>
Change the properties of an identity column. This command is similar to the commands used for changing the properties of named SEQUENCE objects discussed earlier and can use the same options.
ALTER TABLE mytable ALTER COLUMN id RESTART WITH 1000 ALTER TABLE mytable ALTER COLUMN id SET INCREMENT BY 5
DROP GENERATED
drop column identity generator
<drop column identity specification> ::= DROP
GENERATED
Removes the identity generator from a column. After executing this statement, the column values are no longer generated automatically. This option is specific to HyperSQL
ALTER TABLE mytable ALTER COLUMN id DROP GENERATED
SET [ NOT ] NULL
alter column nullability
<alter column nullability> ::= SET [ NOT ]
NULL
Adds or removes a NOT NULL constraint from a column. This option is specific to HyperSQL
CREATE VIEW
view definition
<view definition> ::= CREATE VIEW [ IF NOT
EXISTS ] <table name> <view specification> AS <query
expression> [ WITH [ CASCADED | LOCAL ] CHECK OPTION
]
<view specification> ::= [ <left paren>
<view column list> <right paren> ]
<view column list> ::= <column name
list>
Define a view. The <query expression>
is a SELECT or similar statement. The <view column
list>
is the list of unique names for the columns of the
view. The number of columns in the <view column
list>
must match the number of columns returned by the
<query expression>
. If <view column
list>
is not specified, then the columns of the
<query expression>
should have unique names and
are used as the names of the view column.
Some views are updatable. As covered elsewhere, an updatable
view is based on a single table or updatable view. For updatable views,
the optional CHECK OPTION
clause can be specified. If
this option is specified, then if a row of the view is updated or a new
row is inserted into the view, then it should contain such values that
the row would be included in the view after the change. If WITH
CASCADED CHECK OPTION
is specified, then if the
<query expression>
of the view references
another view, then the search condition of the underlying view should
also be satisfied by the update or insert operation.
DROP VIEW
drop view statement
<drop view statement> ::= DROP VIEW [ IF EXISTS
] <table name> [ IF EXISTS ] <drop
behavior>
Destroy a view. The <drop behavior>
is
similar to dropping a table.
ALTER VIEW
alter view statement
<alter view statement> ::= ALTER VIEW <table
name> <view specification> AS <query expression> [ WITH [
CASCADED | LOCAL ] CHECK OPTION ]
Alter a view. The statement is otherwise identical to CREATE VIEW. The new definition replaces the old. If there are database objects such as routines or views that reference the view, then these objects are recompiled with the new view definition. If the new definition is not compatible, the statement fails.
CREATE DOMAIN
domain definition
<domain definition> ::= CREATE DOMAIN <domain
name> [ AS ] <predefined type> [ <default clause> ] [
<domain constraint>... ] [ <collate clause>
]
<domain constraint> ::= [ <constraint name
definition> ] <check constraint definition> [ <constraint
characteristics> ]
Define a domain. Although a DOMAIN is not strictly a type in the
SQL Standard, it can be informally considered as a type. A DOMAIN is
based on a <predefined type>
, which is a base
type defined by the Standard. It can have a <default
clause>
, similar to a column default clause. It can also
have one or more CHECK constraints which limit the values that can be
assigned to a column that has the DOMAIN as its type. The keyword VALUE
is used in the constraint definition to refer to the value of the
column.
If a column uses a domain that contains a <default
clause>
, it can have a column default clause as well, which
overrides the default defined by the domain. In a table that contains a
column based on a domain, the CHECK constraints in table definition
apply in addition to the CHECK constraints of the domain.
CREATE DOMAIN valid_string AS VARCHAR(20) DEFAULT 'NO VALUE' CHECK (VALUE IS NOT NULL AND CHARACTER_LENGTH(VALUE) > 2)
ALTER DOMAIN
alter domain statement
<alter domain statement> ::= ALTER DOMAIN
<domain name> <alter domain action>
<alter domain action> ::= <set domain default
clause> | <drop domain default clause> | <add domain
constraint definition> | <drop domain constraint
definition>
Change a domain and its definition.
SET DEFAULT
set domain default clause
<set domain default clause> ::= SET <default
clause>
Set the default value in a domain. This is allowed if the domain is already used in a table definition.
DROP DEFAULT
drop domain default clause
<drop domain default clause> ::= DROP
DEFAULT
Remove the default clause of a domain. This is allowed if the domain is already used in a table definition. If a column uses the domain as its type, the domain default is removed. If there is no existing column default clause, the default clause of the domain becomes the column default clause.
ADD CONSTRAINT
add domain constraint definition
<add domain constraint definition> ::= ADD
<domain constraint>
Add a constraint to a domain. This is allowed if the domain is already used in a table definition and the table data satisfies the constraint.
DROP CONSTRAINT
drop domain constraint definition
<drop domain constraint definition> ::= DROP
CONSTRAINT <constraint name>
Remove a constraint on a domain. This is allowed if the domain is already used in a table definition. The constraint no longer applies to a column that uses the domain as its type.
DROP DOMAIN
drop domain statement
<drop domain statement> ::= DROP DOMAIN
<domain name> <drop behavior>
Destroy a domain. If <drop behavior>
is
not CASCADE
, an exception is raised if the domain is
already used in any database object. When CASCADE
is
specified, it works differently from most other cascading operations. If
a table features a column that has specified DOMAIN, the column survives
and inherits the base data type of the domain. The default clause and
the check constraint of the DOMAIN no longer apply to the column (this
behaviour is different from the SQL Standard).
CREATE TRIGGER
trigger definition
<trigger definition> ::= CREATE TRIGGER
<trigger name> <trigger action time> <trigger event>
ON <table name> [ REFERENCING <transition table or variable
list> ] <triggered action>
<trigger action time> ::= BEFORE | AFTER |
INSTEAD OF
<trigger event> ::= INSERT | DELETE | UPDATE [
OF <trigger column list> ]
<trigger column list> ::= <column name
list>
<triggered action> ::= [ FOR EACH { ROW |
STATEMENT } ] [ <triggered when clause> ] <triggered SQL
statement>
<triggered when clause> ::= WHEN <left
paren> <search condition> <right
paren>
<triggered SQL statement> ::= <SQL procedure
statement> | BEGIN ATOMIC { <SQL procedure statement>
<semicolon> }... END | [QUEUE <integer literal>] [NOWAIT]
CALL <HSQLDB trigger class FQN>
<transition table or variable list> ::=
<transition table or variable>...
<transition table or variable> ::= OLD [ ROW ] [
AS ] <old transition variable name> | NEW [ ROW ] [ AS ] <new
transition variable name> | OLD TABLE [ AS ] <old transition table
name> | NEW TABLE [ AS ] <new transition table
name>
<old transition table name> ::= <transition
table name>
<new transition table name> ::= <transition
table name>
<transition table name> ::=
<identifier>
<old transition variable name> ::=
<correlation name>
<new transition variable name> ::=
<correlation name>
Trigger definition is a relatively complex statement. The
combination of <trigger action time>
and
<trigger event>
determines the type of the
trigger. Examples include BEFORE DELETE, AFTER UPDATE, INSTEAD OF
INSERT. If the optional [ OF <trigger column list>
]
is specified for an UPDATE trigger, then the trigger is
activated only if one of the columns that is in the <trigger
column list>
is specified in the UPDATE statement that
activates the trigger.
If a trigger is FOR EACH ROW
, which is the
default option, then the trigger is activated for each row of the table
that is affected by the execution of an SQL statement. Otherwise, it is
activated once only per statement execution. In the first case, there is
a before and after state for each row. For UPDATE triggers, both before
and after states exist, representing the row before the update, and
after the update. For DELETE, triggers, there is only a before state.
For INSERT triggers, there is only an after state. If a trigger is
FOR EACH STATEMENT
, then a transient table is created
containing all the rows for the before state and another transient table
is created for the after state.
The [ REFERENCING <transition table or variable>
]
is used to give a name to the before and after data row or
table. This name can be referenced in the <SQL procedure
statement>
to access the data.
The optional <triggered when clause>
is a
search condition, similar to the search condition of a DELETE or UPDATE
statement. If the search condition is not TRUE for a row, then the
trigger is not activated for that row.
The <SQL procedure statement>
is limited
to INSERT, DELETE, UPDATE and MERGE statements.
The <HSQLDB trigger class FQN>
is a
delimited identifier that contains the fully qualified name of a Java
class that implements the org.hsqldb.Trigger
interface.
HyperSQL does not yet allow the use of OLD TABLE or NEW TABLE in statement level trigger definitions.
DROP TRIGGER
drop trigger statement
<drop trigger statement> ::= DROP TRIGGER
<trigger name>
Destroy a trigger.
schema routine
SQL-invoked routine
<SQL-invoked routine> ::= <schema
routine>
<schema routine> ::= <schema procedure> |
<schema function>
<schema procedure> ::= CREATE <SQL-invoked
procedure>
<schema function> ::= CREATE <SQL-invoked
function>
<SQL-invoked procedure> ::= PROCEDURE <schema
qualified routine name> <SQL parameter declaration list>
<routine characteristics> <routine body>
<SQL-invoked function> ::= { <function
specification> | <method specification designator> }
<routine body>
<SQL parameter declaration list> ::= <left
paren> [ <SQL parameter declaration> [ { <comma> <SQL
parameter declaration> }... ] ] <right
paren>
<SQL parameter declaration> ::= [ <parameter
mode> ] [ <SQL parameter name> ] <parameter type> [
RESULT ]
<parameter mode> ::= IN | OUT |
INOUT
<parameter type> ::= <data
type>
<function specification> ::= FUNCTION <schema
qualified routine name> <SQL parameter declaration list>
<returns clause> <routine characteristics> [ <dispatch
clause> ]
<method specification designator> ::= SPECIFIC
METHOD <specific method name> | [ INSTANCE | STATIC | CONSTRUCTOR
] METHOD <method name> <SQL parameter declaration list> [
<returns clause> ] FOR <schema-resolved user-defined type
name>
<routine characteristics> ::= [ <routine
characteristic>... ]
<routine characteristic> ::= <language
clause> | <parameter style clause> | SPECIFIC <specific
name> | <deterministic characteristic> | <SQL-data access
indication> | <null-call clause> | <returned result sets
characteristic> | <savepoint level
indication>
<savepoint level indication> ::= NEW SAVEPOINT
LEVEL | OLD SAVEPOINT LEVEL
<returned result sets characteristic> ::=
DYNAMIC RESULT SETS <maximum returned result
sets>
<parameter style clause> ::= PARAMETER STYLE
<parameter style>
<dispatch clause> ::= STATIC
DISPATCH
<returns clause> ::= RETURNS <returns
type>
<returns type> ::= <returns data type> [
<result cast> ] | <returns table type>
<returns table type> ::= TABLE <table
function column list>
<table function column list> ::= <left
paren> <table function column list element> [ { <comma>
<table function column list element> }... ] <right
paren>
<table function column list element> ::=
<column name> <data type>
<result cast> ::= CAST FROM <result cast from
type>
<result cast from type> ::= <data type> [
<locator indication> ]
<returns data type> ::= <data type> [
<locator indication> ]
<routine body> ::= <SQL routine spec> |
<external body reference>
<SQL routine spec> ::= [ <rights clause> ]
<SQL routine body>
<rights clause> ::= SQL SECURITY INVOKER | SQL
SECURITY DEFINER
<SQL routine body> ::= <SQL procedure
statement>
<external body reference> ::= EXTERNAL [ NAME
<external routine name> ] [ <parameter style clause>
]
<parameter style> ::= SQL |
GENERAL
<deterministic characteristic> ::= DETERMINISTIC
| NOT DETERMINISTIC
<SQL-data access indication> ::= NO SQL |
CONTAINS SQL | READS SQL DATA | MODIFIES SQL DATA
<null-call clause> ::= RETURNS NULL ON NULL
INPUT | CALLED ON NULL INPUT
<maximum returned result sets> ::= <unsigned
integer>
Define an SQL-invoked routine. A few of the options are not used by HyperSQL and have default behaviours. See the SQL-Invoked Routines chapter for more details of various options and examples.
ALTER routine
alter routine statement
<alter routine statement> ::= ALTER <specific
routine designator> [ <alter routine characteristics> ] [
RESTRICT ] <routine body>
<alter routine characteristics> ::= <alter
routine characteristic>...
<alter routine characteristic> ::= <language
clause> | <parameter style clause> | <SQL-data access
indication> | <null-call clause> | <returned result sets
characteristic>
<alter routine body> ::= <SQL routine
body>
Alter the characteristic and the body of an SQL-invoked routine. If RESTRICT is specified and the routine is already used in a different routine or view definition, an exception is raised. Altering the routine changes the implementation without changing the parameters. Defining recursive SQL/PSM SQL functions is only possible by altering a non-recursive routine body. An example is given in the SQL-Invoked Routines chapter.
An example is given below for a function defined as a Java method, then redefined as an SQL function.
CREATE FUNCTION zero_pad(x BIGINT, digits INT, maxsize INT) RETURNS CHAR VARYING(100) SPECIFIC zero_pad_01 NO SQL DETERMINISTIC LANGUAGE JAVA EXTERNAL NAME 'CLASSPATH:org.hsqldb.lib.StringUtil.toZeroPaddedString'; ALTER SPECIFIC ROUTINE zero_pad_01 LANGUAGE SQL BEGIN ATOMIC DECLARE str VARCHAR(128); SET str = CAST(x AS VARCHAR(128)); SET str = SUBSTRING('0000000000000' FROM 1 FOR digits - CHAR_LENGTH(str)) + str; return str; END
DROP
drop routine statement
<drop routine statement> ::= DROP <specific
routine designator> <drop behavior>
Destroy an SQL-invoked routine.
CREATE SEQUENCE
sequence generator definition
<sequence generator definition> ::= CREATE
SEQUENCE [ IF NOT EXISTS ] <sequence generator name> [
<sequence generator options> ]
<sequence generator options> ::= <sequence
generator option> ...
<sequence generator option> ::= <sequence
generator data type option> | <common sequence generator
options>
<common sequence generator options> ::=
<common sequence generator option> ...
<common sequence generator option> ::=
<sequence generator start with option> | <basic sequence
generator option>
<basic sequence generator option> ::=
<sequence generator increment by option> | <sequence generator
maxvalue option> | <sequence generator minvalue option> |
<sequence generator cycle option>
<sequence generator data type option> ::= AS
<data type>
<sequence generator start with option> ::= START
WITH <sequence generator start value>
<sequence generator start value> ::= <signed
numeric literal>
<sequence generator increment by option> ::=
INCREMENT BY <sequence generator increment>
<sequence generator increment> ::= <signed
numeric literal>
<sequence generator maxvalue option> ::=
MAXVALUE <sequence generator max value> | NO
MAXVALUE
<sequence generator max value> ::= <signed
numeric literal>
<sequence generator minvalue option> ::=
MINVALUE <sequence generator min value> | NO
MINVALUE
<sequence generator min value> ::= <signed
numeric literal>
<sequence generator cycle option> ::= CYCLE | NO
CYCLE
Define a named sequence generator. A SEQUENCE object generates a
sequence of integers according to the specified rules. The simple
definition without the options defines a sequence of numbers in INTEGER
type starting at 1 and incrementing by 1. By default, the
CYCLE
property is set and the minimum and maximum
limits are the minimum and maximum limits of the type of returned
values. There are self-explanatory options for changing various
properties of the sequence. The MAXVALUE
and
MINVALUE
specify the upper and lower limits. If
CYCLE
is specified, after the sequence returns the
highest or lowest value in range, the next value will respectively be
the lowest or highest value in range. If NO CYCLE
is
specified, the use of the sequence generator results in an error once
the limit has been reached.
The integer types: SMALLINT, INTEGER, BIGINT, DECIMAL and NUMERIC can be used as the type of the sequence. DECIMAL and NUMERIC types must have a scale of 0 and a precision not exceeding 18.
ALTER SEQUENCE
alter sequence generator statement
<alter sequence generator statement> ::= ALTER
SEQUENCE <sequence generator name> <alter sequence generator
options>
<alter sequence generator options> ::= <alter
sequence generator option>...
<alter sequence generator option> ::= <alter
sequence generator restart option> | <basic sequence generator
option>
<alter sequence generator restart option> ::=
RESTART [ WITH <sequence generator restart value>
]
<sequence generator restart value> ::=
<signed numeric literal>
Change the definition of a named sequence generator. The same
options that are used in the definition of the SEQUENCE can be used to
alter it. The exception is the option for the start value which is
RESTART WITH
for the ALTER SEQUENCE statement.
If RESTART is used by itself (without a value), then the current value of the sequence is reset to the start value. Otherwise, the current value is reset to the given restart value.
DROP SEQUENCE
drop sequence generator statement
<drop sequence generator statement> ::= DROP
SEQUENCE [ IF EXISTS ] <sequence generator name> [ IF EXISTS ]
<drop behavior>
Destroy an external sequence generator. If the <drop
behavior>
is CASCADE
, then all objects
that reference the sequence are dropped. These objects can be VIEW,
ROUTINE or TRIGGER objects.
SQL procedure statement
SQL procedure statement
The definition of CREATE TRIGGER and CREATE PROCEDURE
statements refers to <SQL procedure statement>
.
The definition of this element is given below. However, only a subset of
these statements is allowed in trigger or routine definition.
<SQL procedure statement> ::= <SQL executable
statement>
<SQL executable statement> ::= <SQL schema
statement> | <SQL data statement> | <SQL control
statement> | <SQL transaction statement> | <SQL connection
statement> | <SQL session statement> | <SQL diagnostics
statement> | <SQL dynamic statement>
<SQL schema statement> ::= <SQL schema
definition statement> | <SQL schema manipulation
statement>
<SQL schema definition statement> ::= <schema
definition> | <table definition> | <view definition> |
<SQL-invoked routine> | <grant statement> | <role
definition> | <domain definition> | <character set
definition> | <collation definition> | <transliteration
definition> | <assertion definition> | <trigger
definition> | <user-defined type definition> | <user-defined
cast definition> | <user-defined ordering definition> |
<transform definition> | <sequence generator
definition>
<SQL schema manipulation statement> ::= <drop
schema statement> | <alter table statement> | <drop table
statement> | <drop view statement> | <alter routine
statement> | <drop routine statement> | <drop user-defined
cast statement> | <revoke statement> | <drop role
statement> | <alter domain statement> | <drop domain
statement> | <drop character set statement> | <drop
collation statement> | <drop transliteration statement> |
<drop assertion statement> | <drop trigger statement> |
<alter type statement> | <drop data type statement> |
<alter sequence generator statement> | <drop sequence generator
statement>
CREATE SYNONYM
create synonym statement
<create synonym statement> ::= CREATE SYNONYM
<synonym name> FOR <target object name>
Creates a synonym for the <target object
name>
. The synonym is defined in the current schema, unless
the name is qualified with a different schema name. The target object
name can be a schema object in the current schema or in another schema.
The synonym can be used only without the schema name.
DROP SYNONYM
drop synonym statement
<drop synonym statement> ::= DROP SYNONYM
<synonym name>
Drops the synonym. The <synonym name>
can
be the simple name of the synonym or qualified with the schema
name.
CREATE INDEX
create index statement
<create index statement> ::= CREATE INDEX [ IF
NOT EXISTS ] <index name> ON <table name> <left paren>
{<column name> [ASC | DESC]}, ... <right
paren>
Creates an index on a group of columns of a table. The optional [ASC | DESC] specifies if the column is indexed in the ascending or descending order, but has no effect on how the index is created (it is allowed for compatibility with other database engines). HyperSQL can use all indexes in ascending or descending order as needed. Indexes should not duplicate the columns of PRIMARY KEY, UNIQUE or FOREIGN key constraints as each of these constraints creates an index automatically.
DROP INDEX
drop index statement
<drop index statement> ::= DROP INDEX [ IF
EXISTS ] <index name> [ IF EXISTS ]
Destroy an index.
ALTER INDEX
change the columns of an index
<alter index statement> ::= ALTER INDEX
<index name> <left paren> {<column name>} , ...
<right paren>
Redefine an index with a new column list. This statement is more efficient than dropping an existing index and creating a new one.
ALTER CONSTRAINT
alter foreign key constraint definition
<alter constraint definition> ::= ALTER
CONSTRAINT <constraint name> INDEX ADD <left paren>
<extra column list> <right paren>
Add extra columns to the index of a FOREIGN KEY constraint. Only the index is extended over the extra columns and the FOREIGN KEY does not change. If the statement is used again, the previous extra columns of the index are replaced with the new extra columns. The FOREIGN KEY must have a user-defined name.
CREATE TYPE
user-defined type definition
<user-defined type definition> ::= CREATE TYPE
<user-defined type body>
<user-defined type body> ::= <schema-resolved
user-defined type name> [ AS <representation>
]
<representation> ::= <predefined
type>
Define a user-defined type. Currently only simple distinct types can be defined without further attributes.
CREATE CAST
user-defined cast definition
<user-defined cast definition> ::= CREATE CAST
<left paren> <source data type> AS <target data type>
<right paren> WITH <cast function> [ AS ASSIGNMENT
]
<cast function> ::= <specific routine
designator>
<source data type> ::= <data
type>
<target data type> ::= <data
type>
Define a user-defined cast. This feature may be supported in a future version of HyperSQL.
DROP CAST
drop user-defined cast statement
<drop user-defined cast statement> ::= DROP CAST
<left paren> <source data type> AS <target data type>
<right paren> <drop behavior>
Destroy a user-defined cast. This feature may be supported in a future version of HyperSQL.
CREATE CHARACTER SET
character set definition
<character set definition> ::= CREATE CHARACTER
SET <character set name> [ AS ] <character set source> [
<collate clause> ]
<character set source> ::= GET <character set
specification>
Define a character set. A new CHARACTER SET is based on an
existing CHARACTER SET. The optional <collate
clause>
specifies the collation to be used, otherwise the
collation is inherited from the default collation for the source
CHARACTER SET. Currently this statement has no effect, as the character
set used by HyperSQL is Unicode and there is no need for subset
character sets.
DROP CHARACTER SET
drop character set statement
<drop character set statement> ::= DROP
CHARACTER SET <character set name>
Destroy a character set. If the character set name is
referenced in any database object, the command fails. Note that
CASCADE
or RESTRICT
cannot be
specified for this command.
CREATE COLLATION
collation definition
<collation definition> ::= CREATE COLLATION
<collation name> FOR <character set specification> FROM
<existing collation name> [ <pad characteristic>
]
<existing collation name> ::= <collation
name>
<pad characteristic> ::= NO PAD | PAD
SPACE
Define a collation. A new collation is based on an existing
COLLATION and applies to an existing CHARACTER SET. The
<character set specification>
is always
SQL_TEXT. The <existing collation name>
is
either SQL_TEXT or one of the language collations supported by HyperSQL.
The <pad characteristic>
specifies whether
strings are padded with spaces for comparison.
This statement is typically used when a collation is required that
does not pad spaces before comparing two strings. For example,
CREATE COLLATION FRENCH_NOPAD FOR INFORMATION_SCHEMA.SQL_TEXT
FROM "French" NO PAD
, results in a French collation without
padding. This collation can be used for sorting or for individual
columns of tables.
DROP COLLATION
drop collation statement
<drop collation statement> ::= DROP COLLATION
<collation name> <drop behavior>
Destroy a collation. If the <drop
behavior>
is CASCADE
, then all
references to the collation revert to the default collation that would
be in force if the dropped collation was not specified.
CREATE TRANSLATION
transliteration definition
<transliteration definition> ::= CREATE
TRANSLATION <transliteration name> FOR <source character set
specification> TO <target character set specification> FROM
<transliteration source>
<source character set specification> ::=
<character set specification>
<target character set specification> ::=
<character set specification>
<transliteration source> ::= <existing
transliteration name> | <transliteration
routine>
<existing transliteration name> ::=
<transliteration name>
<transliteration routine> ::= <specific
routine designator>
Define a character transliteration. This feature may be supported in a future version of HyperSQL.
DROP TRANSLATION
drop transliteration statement
<drop transliteration statement> ::= DROP
TRANSLATION <transliteration name>
Destroy a character transliteration. This feature may be supported in a future version of HyperSQL.
CREATE ASSERTION
assertion definition
<assertion definition> ::= CREATE ASSERTION
<constraint name> CHECK <left paren> <search
condition> <right paren> [ <constraint characteristics>
]
Specify an integrity constraint. This feature may be supported in a future version of HyperSQL.
DROP ASSERTION
drop assertion statement
<drop assertion statement> ::= DROP ASSERTION
<constraint name> [ <drop behavior> ]
Destroy an assertion. This feature may be supported in a future version of HyperSQL.
The Information Schema is a special schema in each catalog. The SQL Standard defines a number of character sets and domains in this schema. In addition, all the implementation-defined collations belong to the Information Schema.
The SQL Standard defines many views in the Information Schema. These views show the properties of the database objects that currently exist in the database. When a user accesses one these views, only the properties of database objects that the user can access are included.
HyperSQL supports all the views defined by the Standard, apart from a few views that report on extended user-defined types and other optional features of the Standard that are not supported by HyperSQL.
HyperSQL also adds some views to the Information Schema. These views are for features that are not reported in any of the views defined by the Standard, or for use by JDBC DatabaseMetaData.
Each database object may reference other database objects. For example, a VIEW references tables in its SELECT statement. An SQL FUNCTION or PROCEDURE typically references tables, views, other routines, and sequences. There are views in the INFORMATION_SCHEMA with the word "USAGE" in the name. Each of these views lists references to objects of a particular type from a particular type, for example references to tables from routines.
From version 2.5.0, a new SQL statement lists all the database objects that use (reference) a particular database object. Alternatively, the statement lists all the database object that are used (referenced) by a particular database object.
EXPLAIN REFERENCES
explain references
<explain references statement> ::= EXPLAIN
REFERENCES { TO | FROM } { TABLE | VIEW | DOMAIN | TYPE | SPACIFIC
ROUTINE | SEQUENCE > <object name>
For example, EXPLAIN REFERENCES TO TABLE
T1
.
The SQL Standard defines a number of character sets and domains in the INFORMATION SCHEMA.
These domains are used in the INFORMATION SCHEMA views:
CARDINAL_NUMBER, YES_OR_NO, CHARACTER_DATA, SQL_IDENTIFIER, TIME_STAMP
All available collations are in the INFORMATION SCHEMA.
HyperSQL supports a vast range of views in the INFORMATION_SCHEMA. These include views specified by the SQL Standard, SQL/Schemata part, plus views that are specific to HyperSQL and are used for JDBC DatabaseMetaData queries, which are based on SQL/CLI part, or other information that is not covered by the SQL Standard. The names of views that are not part of SQL/Schemata start with SYSTEM_.
The views cover different types of information. These are covered in the next sections.
Users with the special ADMIN role can see the full information on all database objects. Ordinary, non-admin users can see information on the objects for which they have some privileges.
The rows returned to a non-admin user exclude objects on which the user has no privilege. The extent of the information in visible rows varies with the user's privilege. For example, the owner of a VIEW can see the text of the view query, but a user of the view cannot see this text. When a user cannot see the contents of some column, null is returned for that column.
The names of database objects are stored in hierarchical views. The top level view is INFORMATION_SCHEMA_CATALOG_NAME.
Below this level, there is a group of views that covers authorizations and roles, without referencing schema objects. These are AUTHORIZATIONS and ADMINSTRABLE_ROLE_AUTHORIZATIONS.
Also below the top level, there is the SCHEMATA view, which lists the schemas in the catalog.
The views that refer to top-level schema objects are divided by object type. These includes ASSERTIONS, CHARACTER_SETS, COLLATIONS, DOMAINS, ROUTINES, SEQUENCES, TABLES, USER_DEFINED_TYPES and VIEWS.
There are views that refer to objects that are dependent on the top-level schema objects. These include COLUMNS and PARAMETERS, views for constraints, including CHECK_CONSTRAINTS, REFERENTIAL_CONSTRAINTS and TABLE_CONSTRAINTS, and finally the TRIGGERS view.
The usage of each type of top-level object by another is covered by several views. For example, TRIGGER_SEQUENCE_USAGE or ROUTINE_TABLE_USAGE.
Several other views list the individual privileges owned or granted to each AUTHORIZATION. For example, ROLE_ROUTINE_GRANTS or TABLE_PRIVILEGES.
The INFORMATION_SCHEMA contains comprehensive information on the data types of each schema object and its elements. For example, the ROUTINES view includes the return data type for each FUNCTION definition. The columns for this information contain nulls for rows that cover PROCEDURE definitions.
The COLUMNS, PARAMETERS and SEQUENCES views contain the type information in columns with similar names.
The type information for ARRAY types is returned in the ELEMENT_TYPES view. When a row of the COLUMNS or other view indicates that the type of the object is an ARRAY type, then there is a corresponding entry for this row in the ELEMENT_TYPES view. The following columns in the ELEMENTS_TYPES view identify the database object whose data type is being described: OBJECT_CATALOG, OBJECT_SCHEMA, OBJECT_NAME, OBJECT_TYPE, COLLECTION_TYPE_IDENTIFIER. The last column's counterpart in the COLUMNS view is named differently as DTD_IDENTIFIER. So in order to determine the array element type of a column, an equi-join between the COLUMNS and ELEMENT_TYPES tables on the six listed columns in the ELEMENT_TYPES view and their counterparts in the COLUMNS view is needed.
A group of views, including SQL_IMPLEMENTATION_INFO, SQL_FEATURES, SQL_SIZING and others cover the capabilities of HyperSQL in detail. These views hold static data and can be explored even when the database is empty.
There are some HyperSQL custom views cover the current state of operation of the database. These include SYSTEM_CACHEINFO, SYSTEM_SESSIONINFO and SYSTEM_SESSIONS views.
The following views are defined by the SQL Standard and supported by HyperSQL. The columns and contents exactly match the Standard requirements.
ADMINISTRABLE_ROLE_AUTHORIZATIONS
Information on ROLE authorizations, all granted by the admin role.
APPLICABLE_ROLES
Information on ROLE authorizations for the current user
ASSERTIONS
Empty view as ASSERTION objects are not yet supported.
AUTHORIZATIONS
Top level information on USER and ROLE objects in the database
CHARACTER_SETS
List of supported CHARACTER SET objects
CHECK_CONSTRAINTS
Additional information specific to each CHECK constraint, including the search condition
CHECK_CONSTRAINT_ROUTINE_USAGE
Information on FUNCTION objects referenced in CHECK constraints search conditions
COLLATIONS
Information on collations supported by the database.
COLUMNS
Information on COLUMN objects in TABLE and VIEW definitions
COLUMN_COLUMN_USAGE
Information on references to COLUMN objects from other, GENERATED, COLUMN objects
COLUMN_DOMAIN_USAGE
Information on DOMAIN objects used in type definition of COLUMN objects
COLUMN_PRIVILEGES
Information on privileges on each COLUMN object, granted to different ROLE and USER authorizations
COLUMN_UDT_USAGE
Information on distinct TYPE objects used in type definition of COLUMN objects
CONSTRAINT_COLUMN_USAGE
Information on COLUMN objects referenced by CONSTRAINT objects in the database
CONSTRAINT_PERIOD_USAGE
Information on application PERIOD objects referenced by CONSTRAINT objects in the database
CONSTRAINT_TABLE_USAGE
Information on TABLE and VIEW objects referenced by CONSTRAINT objects in the database
DATA_TYPE_PRIVILEGES
Information on top level schema objects of various kinds that reference TYPE objects
DOMAINS
Top level information on DOMAIN objects in the database.
DOMAIN_CONSTRAINTS
Information on CONSTRAINT definitions used for DOMAIN objects
ELEMENT_TYPES
Information on the type of elements of ARRAY used in database columns or routine parameters and return values
ENABLED_ROLES
Information on ROLE privileges enabled for the current session
INFORMATION_SCHEMA_CATALOG_NAME
Information on the single CATALOG object of the database
KEY_COLUMN_USAGE
Information on COLUMN objects of tables that are used by PRIMARY KEY, UNIQUE and FOREIGN KEY constraints
KEY_PERIOD_USAGE
Information on application PERIOD objects that are used by PRIMARY KEY, UNIQUE and FOREIGN KEY constraints
PARAMETERS
Information on parameters of each FUNCTION or PROCEDURE
PERIODS
Information on PERIOD objects defined in tables
REFERENTIAL_CONSTRAINTS
Additional information on FOREIGN KEY constraints, including triggered action and name of UNIQUE constraint they refer to
ROLE_AUTHORIZATION_DESCRIPTORS
ROLE_COLUMN_GRANTS
Information on privileges on COLUMN objects granted to or by the current session roles
ROLE_ROUTINE_GRANTS
Information on privileges on FUNCTION and PROCEDURE objects granted to or by the current session roles
ROLE_TABLE_GRANTS
Information on privileges on TABLE and VIEW objects granted to or by the current session roles
ROLE_UDT_GRANTS
Information on privileges on TYPE objects granted to or by the current session roles
ROLE_USAGE_GRANTS
Information on privileges on USAGE privileges granted to or by the current session roles
ROUTINE_COLUMN_USAGE
Information on COLUMN objects of different tables that are referenced in FUNCTION and PROCEDURE definitions
ROUTINE_JAR_USAGE
Information on JAR usage by Java language FUNCTION and PROCEDURE objects.
ROUTINE_PERIOD_USAGE
Information on table PERIOD objects referenced in FUNCTION and PROCEDURE objects.
ROUTINE_PRIVILEGES
Information on EXECUTE privileges granted on PROCEDURE and FUNCTION objects
ROUTINE_ROUTINE_USAGE
Information on PROCEDURE and FUNCTION objects that are referenced in FUNCTION and PROCEDURE definitions
ROUTINE_SEQUENCE_USAGE
Information on SEQUENCE objects that are referenced in FUNCTION and PROCEDURE definitions
ROUTINE_TABLE_USAGE
Information on TABLE and VIEW objects that are referenced in FUNCTION and PROCEDURE definitions
ROUTINES
Top level information on all PROCEDURE and FUNCTION objects in the database
SCHEMATA
Information on all the SCHEMA objects in the database
SEQUENCES
Information on SEQUENCE objects
SQL_FEATURES
List of all SQL:2023 standard core and optional features, including information on whether they are supported or not supported by HyperSQL
SQL_IMPLEMENTATION_INFO
Information on name, capabilities and defaults of the database engine software.
SQL_PACKAGES
List of SQL:2011 Standard packages, including information on whether they are supported or not supported by HyperSQL
SQL_PARTS
List of the SQL:2011 Standard parts, including information on whether they are supported or not supported by HyperSQL
SQL_SIZING
List of the SQL:2011 Standard maximum supported sizes for different features as supported by HyperSQL
SQL_SIZING_PROFILES
TABLES
Information on all TABLE and VIEW object, including the INFORMATION_SCHEMA views themselves
TABLE_CONSTRAINTS
Information on all table level constraints, including PRIMARY KEY, UNIQUE, FOREIGN KEY and CHECK constraints
TABLE_PRIVILEGES
Information on privileges on TABLE and VIEW objects owned or given to the current user
TRANSLATIONS
TRIGGERED_UPDATE_COLUMNS
Information on columns that have been used in TRIGGER definitions in the ON UPDATE clause
TRIGGERS
Top level information on the TRIGGER definitions in the databases
TRIGGER_COLUMN_USAGE
Information on COLUMN objects that have been referenced in the body of TRIGGER definitions
TRIGGER_PERIOD_USAGE
Information on PERIOD objects that have been referenced in the body of TRIGGER definitions
TRIGGER_ROUTINE_USAGE
Information on FUNCTION and PROCEDURE objects that have been used in TRIGGER definitions
TRIGGER_SEQUENCE_USAGE
Information on SEQUENCE objects that been referenced in TRIGGER definitions
TRIGGER_TABLE_USAGE
Information on TABLE and VIEW objects that have been referenced in TRIGGER definitions
USAGE_PRIVILEGES
Information on USAGE privileges granted to or owned by the current user
USER_DEFINED_TYPES
Top level information on TYPE objects in the database
VIEWS
Top Level information on VIEW objects in the database
VIEW_COLUMN_USAGE
Information on COLUMN objects referenced in the query expressions of the VIEW objects
VIEW_PERIOD_USAGE
Information on PERIOD objects referenced in the query expressions of the VIEW objects
VIEW_ROUTINE_USAGE
Information on FUNCTION and PROCEDURE objects that have been used in the query expressions of the VIEW objects
VIEW_TABLE_USAGE
Information on TABLE and VIEW objects that have been referenced in the query expressions of the VIEW objects
The following views are specific to HyperSQL. Most of these views are used directly by JDBC DatabaseMetaData method calls and are indicated as such. Some views contain information that is specific to HyperSQL and is not covered by the SQL Standard views.
SYSTEM_BESTROWIDENTIFIER
For
DatabaseMetaData.getBestRowIdentifier
SYSTEM_CACHEINFO
Contains the current settings and variables of the data cache used for all CACHED tables, and the data cache of each TEXT table.
SYSTEM_COLUMN_SEQUENCE_USAGE
Contains a row for each column that is defined as GENERATED BY DEFAULT AS SEQUENCE with the column name and sequence name
SYSTEM_COLUMNS
For DatabaseMetaData.getColumns
,
contains a row for each column
SYSTEM_COMMENTS
Contains the user-defined comments added to tables and their columns. Also informational comments on INFORMATION_SCHEMA views
SYSTEM_CONNECTION_PROPERTIES
For
DatabaseMetaData.getClientInfoProperties
SYSTEM_CROSSREFERENCE
Full list of all columns referenced by FOREIGN KEY constraints.
For DatabaseMetaData.getCrossReference
,
getExportedKeys
and
getImportedKeys
.
SYSTEM_INDEXINFO
For
DatabaseMetaData.getIndexInfo
SYSTEM_KEY_INDEX_USAGE
List of system-generated index names for each PRIMARY KEY, UNIQUE and FOREIGN KEY constraint.
SYSTEM_PRIMARYKEYS
For
DatabaseMetaData.getPrimaryKeys
SYSTEM_PROCEDURECOLUMNS
For
DatabaseMetaData.getProcedureColumns
SYSTEM_PROCEDURES
For
DatabaseMetaData.getFunctionColumns
,
getFunctions
and
getProcedures
SYSTEM_PROPERTIES
Contains the current values of all the database level properties. Settings such as SQL rule enforcement, database transaction model and default transaction level are all reported in this view. The names of the properties are listed in the Properties chapter together with the corresponding SQL statements used to change the properties.
SYSTEM_SCHEMAS
For DatabaseMetaData.getSchemas
SYSTEM_SEQUENCES
SYSTEM_SESSIONINFO
Information on the settings and properties of the current session.
SYSTEM_SESSIONS
Information on all open sessions in the database (when used by a DBA user), or just the current session. Includes the current transaction state of each session.
SYSTEM_TABLES
Information on tables and views for
DatabaseMetaData.getTables
SYSTEM_TABLESTATS
Information on table spaces and cardinality for each table
SYSTEM_TABLETYPES
For
DatabaseMetaData.getTableTypes
SYSTEM_TEXTTABLES
Information on the settings of each text table.
SYSTEM_TYPEINFO
For DatabaseMetaData.getTypeInfo
SYSTEM_UDTS
For DatabaseMetaData.getUDTs
SYSTEM_USERS
Contains the list of all users in the database (when used by a DBA user), or just the current user.
SYSTEM_VERSIONCOLUMNS
For DatabaseMetaData.getVersionColumns
.
Contains list of columns of system PERIOD and those with ON UPDATE
CURRENT TIMESTAMP.
$Revision: 6752 $