<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">
<div class="">Hi All,</div>
<div class=""><br class="">
</div>
<div class="">It was great seeing everyone this last week. I have a question on TAP 1.1 I forgot to bring up:</div>
<div class=""><br class="">
</div>
<div class="">For TAP_SCHEMA.Tables, TAP 1.1 says:</div>
<div class=""><br class="">
</div>
<div class="">
<blockquote type="cite" class="">The table_name values must be unique. The value of the table_name should be the string that is recommended for use in querying the table; it may or may not be qualified by schema and catalog name(s) depending on the implementation
requirements.<br class="">
</blockquote>
</div>
<div class="">
<div class=""><br class="">
</div>
</div>
<div class="">I just wanted to say that I think this makes TAP_SCHEMA tables slightly awkward when you deal with multiple catalogs and schemas, and it seems to be mostly in an effort to prevent an additional `schema_name` column in TAP_SCHEMA.Columns, TAP_SCHEMA.Keys,
etc... Relatedly, there's no catalog.</div>
<div class=""><br class="">
</div>
<div class="">So for a theoretical use case, say I have `oracle.bvan.MyTable` where I created my TAP table, where `oracle.bvan` is really the schema_name (since there's not catalog_name).</div>
<div class=""><br class="">
</div>
<div class="">But I also want a table `qserv.bvan.MyTable` and a table `oracle_dev.bvan.MyTable`.</div>
<div class=""><br class="">
</div>
<div class="">This means I have something like the following:</div>
<div class=""><br class="">
</div>
<div class="">
<div class="">
<div class=""><font face="Courier" class="">TAP_SCHEMA.Schemas</font></div>
<div class=""><font face="Courier" class="">| schema_name |</font></div>
<div class=""><font face="Courier" class="">| oracle.bvan |</font></div>
<div class=""><font face="Courier" class="">| oracle_dev.bvan |</font></div>
<div class=""><font face="Courier" class="">| qserv.bvan |</font></div>
<div class=""><font face="Courier" class=""><br class="">
</font></div>
<div class=""><font face="Courier" class=""><br class="">
</font></div>
<div class=""><font face="Courier" class="">TAP_SCHEMA.Tables</font></div>
<div class=""><font face="Courier" class="">| schema_name | table_name |</font></div>
<div class=""><font face="Courier" class="">| oracle.bvan | oracle.bvan.MyTable |</font></div>
<div class=""><font face="Courier" class="">| oracle_dev.bvan | oracle_dev.bvan.MyTable |</font></div>
<div class=""><font face="Courier" class="">| qserv.bvan | qserv.bvan.MyTable |</font></div>
</div>
<div class=""><font face="Courier" class=""><br class="">
</font></div>
</div>
<div class=""><br class="">
</div>
<div class="">Which, from a programmatic standpoint, means that an application must never naively qualify a table name as (
<font face="Courier" class="">schema_name + "." + table_name</font> ) when constructing a query.</div>
<div class=""><br class="">
</div>
<div class="">I suppose that's not a dealbreaker, but I do think it's awkward, and it deviates from the sql99 approach of using the effective "catalog_name", "schema_name", and "table_name" everywhere:</div>
<div class=""><br class="">
</div>
<div class="">(Linking to postgres docs for simplicity):</div>
<div class=""><a href="https://www.postgresql.org/docs/9.1/infoschema-tables.html" class="">https://www.postgresql.org/docs/9.1/infoschema-tables.html</a></div>
<div class=""><a href="https://www.postgresql.org/docs/9.1/infoschema-columns.html" class="">https://www.postgresql.org/docs/9.1/infoschema-columns.html</a></div>
<div class=""><a href="https://www.postgresql.org/docs/9.1/infoschema-table-constraints.html" class="">https://www.postgresql.org/docs/9.1/infoschema-table-constraints.html</a></div>
<div class=""><br class="">
</div>
<div class="">I think I'd personally prefer there to be IDs and there to be joins on IDs rather than names in a future TAP 2.0 so joins are easier, but maybe at least adding schema_name columns to TAP_SCHEMA.Columns and TAP_SCHEMA.Keys, etc... in the future
would be a better approach, and just force a unique constraint on TAP_SCHEMA.Tables for schema_name and table_name, though I would like to see a CATALOG_NAME in there too.</div>
<div class=""><br class="">
</div>
<div class="">Brian</div>
<div class=""><br class="">
</div>
</body>
</html>