<div dir="ltr">Hi Laurent, hi all,<div>I like your proposed solution.</div><div>My concern on it is that it requires a mandatory new column in columns table (at least to me it seems so).</div><div>And being this column not present in TAP-1.0 it could break back-compatibility, am I wrong?</div><div><br></div><div>Also, if someone comes up really using catalogs, will we have to redo the exercise for "catalog"."schema" thing?</div><div><br></div><div>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).</div><div><br></div><div>Cheers,</div><div> Marco</div><div><br></div><div><div class="gmail_extra"><br><div class="gmail_quote">2015-04-28 16:21 GMT+02:00 Laurent Michel <span dir="ltr"><<a href="mailto:laurent.michel@astro.unistra.fr" target="_blank">laurent.michel@astro.unistra.fr</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello,<br>
<br>
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.<br>
<br>
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:<span class=""><br>
The value of the table_name should be the string that is<br></span>
recommended for use in querying the table; it may *OR* may not be<br>
qualified by....<br>
<br>
This uncertainty in the column definition requires the clients to do some inference to identify the table name which is source of misinterpretations.<br>
<br>
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.<br>
<br>
I do not think that this issue should be sorted out with some quoting strategy.<br>
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.<br>
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.<br>
<br>
Laurent<div><div class="h5"><br>
<br>
<br>
<br>
Le 28/04/2015 14:18, Mark Taylor a écrit :<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Tue, 28 Apr 2015, Markus Demleitner wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I'd fairly strongly suggest that all DB names should be in a form<br>
ready for usage. While the case:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
+-------------------+-------------+<br>
| table_name | column_name |<br>
+-------------------+-------------+<br>
| B/avo.rad/catalog | Sp-Index |<br>
+-------------------+-------------+<br>
<br>
</blockquote>
<br>
might conceivably be caugt by clients who might themselves see that<br>
Sp-Index simply cannot be a delimited identifier, this is impossible<br>
for a column_name 'FooBar' -- this might work as a regular identifier,<br>
but *if* it's a delimited identifer, only '"FooBar"' will work.<br>
</blockquote>
<br>
I *think* you meant to write instead:<br>
<br>
"... Sp-Index simply cannot be a regular identifier ..."<br>
<br>
If not, I'm afraid I need more elucidation.<br>
<br>
Assuming I've got that right ... then I see your point<br>
(I don't need python to tell me that guessing is evil :-]).<br>
I suspect in that case there are a number of TAP services out there<br>
broken in this respect (taplint hasn't been looking for them up till<br>
now), though disappointingly I can only find a couple of examples<br>
at GAVO DC (vlastripe82.stripe82 column _ct, plus an empty schema<br>
mwsc-e14a which maybe doesn't count).<br>
<br>
A possible alternative: outlaw<br>
delimited-identifiers-that-don't-have-to-be-delimited,<br>
i.e. column_name values which are lexically legal regular identifiers<br>
like FooBar must represent regular identifiers, though values<br>
which are illegal regular identifiers (like Foo-Bar) obviously don't.<br>
Stated like that it sounds a bit complex, though it does fall in<br>
line with your project of marginalising use of delimited identifiers,<br>
and it also has the advantage that none of the logic in my code<br>
needs to change :-).<br>
<br>
Supplementary question: does "form ready for usage" include<br>
quoting to avoid collision with ADQL reserved words?<br>
If so, I've got a few more GAVO column names I can beat you with<br>
(distance, size, date, section).<br>
<br>
Mark<br>
<br>
--<br>
Mark Taylor Astronomical Programmer Physics, Bristol University, UK<br>
<a href="mailto:m.b.taylor@bris.ac.uk" target="_blank">m.b.taylor@bris.ac.uk</a> <a href="tel:%2B44-117-9288776" value="+441179288776" target="_blank">+44-117-9288776</a> <a href="http://www.star.bris.ac.uk/~mbt/" target="_blank">http://www.star.bris.ac.uk/~mbt/</a><br>
<br>
</blockquote>
<br></div></div>
-- <br>
jesuischarlie<br>
<br>
Laurent Michel<br>
SSC XMM-Newton<br>
Tél : <a href="tel:%2B33%20%280%293%2068%2085%2024%2037" value="+33368852437" target="_blank">+33 (0)3 68 85 24 37</a><br>
Fax : +33 (0)3 )3 68 85 24 32<br>
<a href="mailto:laurent.michel@astro.unistra.fr" target="_blank">laurent.michel@astro.unistra.fr</a> <mailto:<a href="mailto:laurent.michel@astro.unistra.fr" target="_blank">laurent.michel@astro.unistra.fr</a>><br>
Université de Strasbourg <<a href="http://www.unistra.fr" target="_blank">http://www.unistra.fr</a>><br>
Observatoire Astronomique<br>
11 Rue de l'Université<br>
F - 67200 Strasbourg<br>
<a href="http://amwdb.u-strasbg.fr/HighEnergy/spip.php?rubrique34" target="_blank">http://amwdb.u-strasbg.fr/HighEnergy/spip.php?rubrique34</a><br>
</blockquote></div><br></div></div></div>