Hi!
On Fri, Dec 19, 2008 at 1:05 AM, Brian Aker <[email protected]> wrote: > Multi-tenancy is the issue for me. Should a user(s) be given a catalog? In the standard catlogs are not given to users, schemas are. A schema is a collection of schema objects (tables, etc) and associated with a user (or role): " 4.2.8.2 SQL-schemas An SQL-schema, often referred to simply as a schema, is a persistent, named collection of descriptors. Any object whose descriptor is in some SQL-schema is known as an SQL-schema object. A schema, the schema objects in it, and the SQL-data described by them are said to be owned by the authorization identifier associated with the schema. SQL-schemas are created and destroyed by execution of SQL-schema statements (or by implementation-defined mechanisms). " The "authorization identifier" is essentially a user (or a role). > Should we just restrict this to schema? Should joins work across them? Not sure what you mean by "restrict this to schema" Joins: in a standard implementation, I think they would. >From this: <table name> ::= <local or schema qualified name> <local or schema qualified name> ::= [ <local or schema qualifier> <period> ] <qualified identifier> <local or schema qualifier> ::= <schema name> | <local qualifier> <schema name> ::= [ <catalog name> <period> ] <unqualified schema name> it follows that <catalog>.<schema>.<table> is a valid table name. If you follow from <joined table> ::= <cross join> | <qualified join> | <natural join> upward, you will arrive at <table name> > Is a catalog a simple namespace issue? yes, with something extra: SQL Standard (2003), book 1 on catalogs, schemas and databases: " 4.2.8.1 Catalogs A catalog is a named collection of SQL-schemas, foreign server descriptors, and foreign data wrapper descriptors in an SQL-environment. The mechanisms for creating and destroying catalogs are implementation- defined. " (I think "foreign server descriptor" is what you create when you do CREATE SERVER for FEDERATED - otherwise this is pretty clear: catalog is a bunch of schemas) So - a catalog contains schemas and some objects. A catalog does seem to act as scope for schemas: 3.1.1.5 fully qualified of a name of some SQL object: with all optional components specified explicitly. NOTE 1 — A fully qualified name does not necessarily identify an object uniquely. For example, although a fully qualified specific name, consisting of a catalog name, a schema name and a specific name, uniquely identifies a routine, a fully qualified routine name doesn't necessarily do so. For those wondering about the standard's notion regarding databases, and the relation to schemas and catalogs: the standard does not use the term "database" in any formal way. " The sites, principally base tables, that contain SQL-data, as described by the contents of the schemas. This data may be thought of as "the database", but the term is not used in ISO/IEC 9075, because it has different meanings in the general context. " > drizzle could avoid the horrible slowness of information_schema, and > > In the current roadmap is to rework I_S so the are not materialized (and use > the same execution path as the engine). > >> some of the impedance mismatches between what is available from the >> server and what the standard apis expect to have available. > > What else are you thinking of? Side note: According to the standard, each catalog has its own information_schema: " 4.2.8.3 The Information Schema Every catalog contains an SQL-schema with the name INFORMATION_SCHEMA that includes the descriptors of a number of schema objects, mostly view definitions, that together allow every descriptor in that catalog to be accessed, but not changed, as though it was SQL-data. " hope this helps. > > Cheers, > -Brian > > -- > _______________________________________________________ > Brian "Krow" Aker, brian at tangent.org > Seattle, Washington > http://krow.net/ <-- Me > http://tangent.org/ <-- Software > _______________________________________________________ > You can't grep a dead tree. > > > > > _______________________________________________ > Mailing list: https://launchpad.net/~drizzle-discuss > Post to : [email protected] > Unsubscribe : https://launchpad.net/~drizzle-discuss > More help : https://help.launchpad.net/ListHelp > -- Roland Bouman http://rpbouman.blogspot.com/ _______________________________________________ Mailing list: https://launchpad.net/~drizzle-discuss Post to : [email protected] Unsubscribe : https://launchpad.net/~drizzle-discuss More help : https://help.launchpad.net/ListHelp
