table_name syntax

[Dave Morris]

Hi Laurent,

On 2015-04-28 15:21, Laurent Michel wrote:
> 
> I do not think that this issue should be sorted out with some quoting 
> strategy.
> The common sense tells that a tap_schema query returning "A.*_B" as
> table name means that the name of the table is "A.*_B" and that the
> double quotes are part of this name. Adding single or double quotes
> must remain the job of the query builder as any other
> formatting/escaping business.
> The point is that to work safely, the client needs to have an
> unambiguous way to get the name of both schemas and tables, which can
> be achieved with schema_name column proposed above.
> 

I think we are suggesting the same thing from different directions:
That the TAP_SCHEMA should provide the original unquoted unqualified 
names for both the schema and table.

The current specification allows any of the following combinations

     +-------------+-----------------------------+
     | schema_name | table_name                  |
     +-------------+-----------------------------+
     | viz4        | "B/avo.rad/catalog"         |
     | viz4        | viz4."B/avo.rad/catalog"    |
     | viz4        | "viz4"."B/avo.rad/catalog"  |
     | "viz4"      | "B/avo.rad/catalog"         |
     | "viz4"      | viz4."B/avo.rad/catalog"    |
     | "viz4"      | "viz4"."B/avo.rad/catalog"  |
     +-------------+-----------------------------+

Due, as you say, to the "may OR may not" in the specification.

Which causes problems when clients such as ours try to parse this to 
recover the original unquoted and unqualified schema and table names.

Mark would prefer to leave the quoting escaping and qualifying to the 
server. He wants to get a single string, that is guaranteed to be unique 
within that TAP service and fully escaped with quotes wherever they are 
required, that he can use as the target table name without any further 
processing.

So for Mark, one of these two would probably be the best option

     +-------------+-----------------------------+
     | schema_name | table_name                  |
     +-------------+-----------------------------+
     | viz4        | viz4."B/avo.rad/catalog"    |
     | "viz4"      | "viz4"."B/avo.rad/catalog"  |
     +-------------+-----------------------------+

Mark - is that correct ?

However, the "may OR may not" in the specification means this complex 
table name is difficult for us to parse to recover the original names.

I'm proposing we have both - the 'ready for use' string for Mark, and 
the original (raw) values alongside.

     
+-------------+-----------------------------+-----------------+--------------------+
     | schema_name | table_name                  | raw_schema_name | 
raw_table_name     |
     
+-------------+-----------------------------+-----------------+--------------------+
     | viz4        | viz4."B/avo.rad/catalog"    | viz4            | 
B/avo.rad/catalog  |
     | "viz4"      | "viz4"."B/avo.rad/catalog"  | viz4            | 
B/avo.rad/catalog  |
     
+-------------+-----------------------------+-----------------+--------------------+

By adding those two extra columns, Mark still has the 'ready for use' 
string, that contains all the quotes and qualifiers needed for instant 
use, and we get the raw values that we need to enable us to do the 
processing ourselves.

Yes - it would be nice to change the definitions so that schema_name and 
table_name contained the raw values and the quoted/qualified name was in 
a new column.

     
+-------------+-----------------------------+---------------------------+
     | schema_name | table_name                  | combined_table_name    
    |
     
+-------------+-----------------------------+-----------------+---------+
     | viz4        | B/avo.rad/catalog           | 
viz4."B/avo.rad/catalog"  |
     
+-------------+-----------------------------+---------------------------+

However, changing the definition of the existing columns is probably 
going to be a lot harder than getting new ones added.

Dave

--------
Dave Morris
Software Developer
Wide Field Astronomy Unit
Institute for Astronomy
University of Edinburgh
--------