table_name syntax

[Marco Molinaro]

Hi Laurent, hi all,
I like your proposed solution.
My concern on it is that it requires a mandatory new column in columns
table (at least to me it seems so).
And being this column not present in TAP-1.0 it could break
back-compatibility, am I wrong?

Also, if someone comes up really using catalogs, will we have to redo the
exercise for "catalog"."schema" thing?

I agree in any case that a transition phase adding the schema_name in
columns table can solve the problem in a neat way (or at least so appears
to me).

Cheers,
    Marco


2015-04-28 16:21 GMT+02:00 Laurent Michel <laurent.michel at astro.unistra.fr>:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dal/attachments/20150428/e5b746c7/attachment.html>