table_name syntax

[Mark Taylor]

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?

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/