TAP 1.1: The table_name values must be unique

[Markus Demleitner]

Dear Brian

Just two brief additional points on why TAP_SCHEMA qualification
rules are what they are.

On Mon, Nov 19, 2018 at 06:20:18PM +0000, Van Klaveren, Brian N. wrote:
> After reading those older emails thinking about it a bit more, I
> think it's mostly okay, but it's still somewhat awkward. I think it
> implies our table names could be any of the following:
> 
> catalog.schema.table
> catalog.schema."table"
> catalog."schema"."table"
> "catalog"."schema"."table"

Right -- this problem was exactly the reason why we require
usage-ready names in tap_schema.tables: *You* can make an informed
decision on how to write table references because you know your
database.  A client inspecting your tap_schema cannot; it doesn't now
which identifiers were delimited in the DDL, it doesn't know if
schemas or even catalogs are or are not required, etc.

And that's the entire reason why we're deviating from the SQL
information schema here.

> I do still think that's awkward for some of the following reasons:
> [...]
> • It's somewhat inconsistent in terms of naming, because we don't
> [[catalog.]schema.]table qualify the column names;

Yes -- that's because qualified column names are not required
anywhere in query construction and would, on the contrary, usually be
harmful (meaning: clients would have to have a partial ADQL parser to
take apart the column_names).

Put yourself in the shoes of a program writing a query (based on,
say, columns identified by UCDs) -- you really need to know the
column names unqualified, as the qualified ones wouldn't work in
something like

  SELECT colName FROM (SELECT TOP 30 * FROM tableName) AS q

-- and conversely, an unqualified table_name wouldn't work here (or
much anywhere else); hence the different treatment.

           -- Markus