table_name syntax

[Mark Taylor]

On Tue, 28 Apr 2015, Dave Morris wrote:

> 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 ?

No, I don't care what's there, as long as I understand what it is.

I just want to know whether I should interpret strange characters
in the relevant TAP_SCHEMA *_name columns as (a) something that I
need to escape before inserting into an ADQL query, or as
(b) something that has already been applied to achieve that escaping.
The discussion so far seems to indicate (b), though not all
services currently comply with that understanding.

For any of the options you've written above, as long as I have
the understanding that this is something intended to be plonked
unaltered into ADQL, I can easily work out what the schema name
is and what the unadorned table name is.  Parsing the thing
enough to work out there are some quotes that need to get pulled off
is not a problem, and I certainly don't think it warrants adding
new mandatory columns to TAP_SCHEMA.  I also think it's sensible
to allow the service to provide either a qualified or unqualified
version of the table_name as they see fit, so that (e.g.)
people/machines can tell they don't need to write
'viz4."B/avo.rad/catalog"' when '"B/avo.rad/catalog"' will do.

> 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.

It's not that hard, and it can be done unambiguously, as long as
it's clear what the syntax actually is.
>From a pragmatic point of view, I'd much rather do that amount
of parsing than try and worry about what TAP version I'm dealing
with and go looking for different TAP_SCHEMA columns based on that
in order to work out what ADQL to write.

Mark

--
Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
m.b.taylor at bris.ac.uk +44-117-9288776  http://www.star.bris.ac.uk/~mbt/