table_name syntax

[Laurent Michel]

Hello,

I'd to tackle with these unregular Vizier names for TapHandle. My implementation is based on the assumption that the Vizier 
"tap_schema.table_columns.table_name" contains the name of the table and nothing else, assumption which can obviously not be 
generalised.

My opinion is that this issue points out a weakness in the TAP specification which is located around *OR* word in the 
'table_name' column definition:
    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....

This uncertainty in the column definition requires the clients to do some inference to identify the table name which is source 
of misinterpretations.

So, instead of defining new columns such as raw_* which will possibly add confusion a some stage. I believe that improving the 
support of unregular table names should be to move towards a better specification of the tap_schema definition. For instance, 
would it not be better to add a column "schema-name" and to stipulate that the "table_name" columns only contains the exact name 
of the table without any other path element? The transition for existing services would be smooth since the presence of the 
schema_name column would greatly help to infer the real table name.

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.

Laurent



Le 28/04/2015 14:18, Mark Taylor a écrit :
> On Tue, 28 Apr 2015, Markus Demleitner wrote:
>
>> I'd fairly strongly suggest that all DB names should be in a form
>> ready for usage.  While the case:
>>
>>>     +-------------------+-------------+
>>>     | table_name        | column_name |
>>>     +-------------------+-------------+
>>>     | B/avo.rad/catalog | Sp-Index    |
>>>     +-------------------+-------------+
>>>
>>
>> might conceivably be caugt by clients who might themselves see that
>> Sp-Index simply cannot be a delimited identifier, this is impossible
>> for a column_name 'FooBar' -- this might work as a regular identifier,
>> but *if* it's a delimited identifer, only '"FooBar"' will work.
>
> I *think* you meant to write instead:
>
>      "... Sp-Index simply cannot be a regular identifier ..."
>
> If not, I'm afraid I need more elucidation.
>
> Assuming I've got that right ... then I see your point
> (I don't need python to tell me that guessing is evil :-]).
> I suspect in that case there are a number of TAP services out there
> broken in this respect (taplint hasn't been looking for them up till
> now), though disappointingly I can only find a couple of examples
> at GAVO DC (vlastripe82.stripe82 column _ct, plus an empty schema
> mwsc-e14a which maybe doesn't count).
>
> A possible alternative: outlaw
> delimited-identifiers-that-don't-have-to-be-delimited,
> i.e. column_name values which are lexically legal regular identifiers
> like FooBar must represent regular identifiers, though values
> which are illegal regular identifiers (like Foo-Bar) obviously don't.
> Stated like that it sounds a bit complex, though it does fall in
> line with your project of marginalising use of delimited identifiers,
> and it also has the advantage that none of the logic in my code
> needs to change :-).
>
> Supplementary question: does "form ready for usage" include
> quoting to avoid collision with ADQL reserved words?
> If so, I've got a few more GAVO column names I can beat you with
> (distance, size, date, section).
>
> 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/
>

-- 
jesuischarlie

Laurent Michel
SSC XMM-Newton
Tél : +33 (0)3 68 85 24 37
Fax : +33 (0)3 )3 68 85 24 32
laurent.michel at astro.unistra.fr <mailto:laurent.michel at astro.unistra.fr>
Université de Strasbourg <http://www.unistra.fr>
Observatoire Astronomique
11 Rue de l'Université
F - 67200 Strasbourg
http://amwdb.u-strasbg.fr/HighEnergy/spip.php?rubrique34