Notes from the SQL 2003 specs

An SQL-schema is a persistent descriptor that includes:

The name of the SQL-schema. [Fine]

The <authorization identifier> of the owner of the SQL-schema. [we need a schema<=>owner user mapping (can be either implicit or explicit), right? Initially, this can be implicitly the admin role, granting any admin user owner rights, at least partially preserving existing authorization semantics?]

The name of the default character set for the SQL-schema.[later, not now, right?]

The <schema path specification> defining the SQL-path for SQL-invoked routines for the SQL-schema. [Not worth considering until we have a schema-qualified database class loader in production and/or a PSM/embedded PL implementation to worry about]

The descriptor of every component of the SQL-schema. [Fine]

In this part of ISO/IEC 9075, the term schema is used only in the sense of SQL-schema. The persistent objects described by the descriptors are said to be owned by or to have been created by the <authorization identifier> of the schema.

Each component descriptor is one of:

A domain descriptor. [Not yet implemented]
A base table descriptor. [Fine]
A view descriptor. [Fine]
A constraint descriptor. [Fine]
A privilege descriptor. [Fine]
A character set descriptor. [Not yet implemented]
A collation descriptor. [Not yet implemented]
A transliteration descriptor. [Not yet implemented]
A user-defined type descriptor. [Not yet implemented]
A routine descriptor. [Not yet implemented]
A sequence generator descriptor. [Fine]

[Maybe we need to (re)think about HSQLDB-specific extensions, such as class grants]

A schema is created initially using a <schema definition> and may be subsequently modified incrementally over time by the execution of <SQL schema statement>s. [Obviously needs <schema definition> DDL support]

<schema name>s are unique within a catalog. [Will explicit catalog specfication (a.k.a. pan-database DDL/DML) ever be possible within a single, purely HSQLDB SQL environment?]

A <schema name> is explicitly or implicitly qualified by a <catalog name> that identifies a catalog. [Fine]

Base tables and views are identified by <table name>s. [Fine]

A <table name> consists of a <schema name> and an <identifier>. [Fine]

The <schema name> identifies the schema in which a persistent base table or view identified by the <table name> is defined. [Fine]

Base tables and views defined in different schemas can have <identifier>s that are equal according to the General Rules of Subclause 8.2, <comparison predicate> . [Fine]

If a reference to a <table name> does not explicitly contain a <schema name>, then a specific <schema name> is implied. The particular <schema name> associated with such a <table name> depends on the context in which the <table name> appears and is governed by the rules for <schema qualified name>. [Have we settled on rules regarding implicit schema?]

If a reference to an SQL-invoked routine that is contained in a <routine invocation> does not explicitly contain a <schema name>, then the SQL-invoked routine is selected from the SQL-path of the schema. [Do we have a roadmap for PSM/Embedded PL/Schema-qualified database class loader, as it pertains to SQL-path for SQL-invoked routines?]

The containing schema of an <SQL schema statement> is defined as the schema identified by the <schema name> implicitly or explicitly contained in the name of the object that is created or manipulated by that SQLstatement. [Fine]