Define PartiQL-system for database name resolution e.g. catalogs, schemas, views, routines.

[RCHowell]

We are motivated to make clear the relationship between PartiQL and SQL in regards to database objects such as catalogs and schemas; but we are motivated to relax some SQL restrictions to make PartiQL adaptable to systems which do not strictly adhere to the SQL specification

Part 1 of the SQL-99 specification defines the SQL-Environment which is composed of several pieces such as,

• SQL-environment
• SQL-agent
• SQL-implementation
• SQL-client
• Catalogs
• SQL-schemas
• SQL-data

Note that schema here means "collection of database entities: tables, routines, triggers, etc." rather than the type description of a table.

These definitions lay out the structure of an SQL-based DBMS and define what identifiers are, and how they are related to the management of data. We seek to define global name (database objects) resolution based upon the rules of SQL while generalizing more flexibility as we work to integrate PartiQL across systems that are not necessarily SQL.

The PartiQL Specification briefly mentions a database environment which is akin to a single catalog and schema, but we have yet-to-define fundamental system concepts such as catalogs, schemas, information_schema, and the SQL PATH. These concepts govern fundamental semantics for table, view, and routine (function/produce) resolution. These rules define placement for the execution of DDL/DML.

PartiQL aims for a relaxation of the fixed hierarchy (catalog > schema > table) of SQL systems so that we may generalize a database structure to be like the hierarchical filesystem abstraction. We have found this structure to better fit real-world systems which either lack schemas (named collections of objects) or nest schemas (again, named collections of database objects not table types). For this reason, we will disambiguate the term "schema" and call these named collections of database entities scopes rather than schemas.