table_name syntax

[Laurent Michel]

Hello Mark,



Le 28/04/2015 18:08, Mark Taylor a écrit :
> I don't really understand this suggestion.
>
> A schema_name column already exists in the tap_schema.tables table.
>
> Marco, are you really saying we need a schema_name column in the
> columns table too?  Would that help?
My understanding is that you can have multiple tables with the same name but in different schemas.
That implies to use a path (schema.table) to reference them in the table_column for instance. The client is supposed to parse
that kind of path to get the  name of the table which can not always be achieved with some Vizier tables, unless using
inferences about the possible double quotes.

My idea is that since tables are located by both a name and a schema then these 2 elements must be given everywhere we need to
locate a table. These 2 elements should never be merged in any tap_schema cell and thus we could get rid of quoting issues.


Laurent


>
> On Tue, 28 Apr 2015, Marco Molinaro wrote:
>
>> 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
>>>
>>
>
> --
> 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