TAP information schema

[Doug Tody]

Regarding the issue of the schema name: as Tony says in simple cases this
could probably be hidden, however there are good reasons why we may want
to provide access to (hence expose) the schema name in ADQL queries.

One case is where a single service provides access to tables in
multiple schemas within the DBMS; if the service provides access
to many tables, this provides a useful way to organize the data.
One could argue that each schema should be exposed as a separate
service, however this would prevent use of any ADQL operations which
combine data from multiple schemas.

Another possible use-case involves how we integrate a local VOSpace
into TAP.  A logical way to provide a VOSpace local to a DBMS is to
implement the VOSpace with a schema (or "database", depending upon what
terminology you use).  Externally this would be seen via the VOSpace
API, but internal to the DBMS it could be seen as a separate schema,
e.g., "vospace".  If tables input to the VOSpace are stored internally
as tables (as they may eventually have to be to be used in a query),
they would be usable directly in ADQL queries by the TAP service,
in combination with ordinary data tables such as read-only catalogs
within the DBMS.

The tableset metadata for such local-VOSpace tables could be
queried either via the VOSpace API or via the TAP service directly.
In TAP_SCHEMA.tables for example they would show up in the list of
tables, with schema_name = "vospace" (or whatever).  A DBMS already
allows all this to be done on a per-user basis using the DBMS security
mechanisms, so the user would see only their data or public data; an
unsecure TAP service would see only public data.

A similar mechansim could conceivably be used for a small table
uploaded in-line as a VOTable in a POST query, as for the multi-region
query case.

Also - while VOSpace integration is an advanced capability, we have
already established that it is a high priority for TAP.  Schemas might
not be the best way to handle integration of a local VOSpace with
the DBMS, but it is worth considering.  It would seem to be a good
way to leverage the existing capabilities provided by a modern DBMS.

I'm still trying to figure out if we really need CATALOG_NAME.  This is
NULL or undefined for some DBMS implementations (MySQL and Informix,
so far as I have been able to check), and in other cases appears to
be fixed for a runtime DBMS context (PostgreSQL, possibly MSSQL).

	- Doug