datatype values in TAP_SCHEMA.columns

[Marco Molinaro]

Dear all,
I must say I've always been quite confused by that table, so thank you a
lot for this mail thread that happened to be clarifying to me.
I agree on Mark's suggestion and if this is accepted we'll change
accordingly our services' TAP_SCHEMA-ta (now we have adql prefixed naming,
but it doesn't change a bit to the service output if we remove it).
Cheers,
   Marco

2014-06-05 10:58 GMT+02:00 Mark Taylor <m.b.taylor at bristol.ac.uk>:

> On Thu, 5 Jun 2014, Markus Demleitner wrote:
>
> > As far as TAP_SCHEMA goes, I think we should be asking ourselves why
> > we expose types there.  And I think the answer has to be: To indicate
> > to clients what operations are supported on references to these
> > columns.  Given that TAP results come in VOTables (unless people void
> > their warranty by ordering something else), they are definitely not
> > necessary to interpret of the results.  I don't even think the types
> > are terribly useful in data discovery.
> >
> > This means: we don't need 100% precision in the type descriptions
> > Thus, I submit we can allow some information loss in going from
> > actual database types to what's in TAP_SCHEMA -- in general, it's
> > basically ok if clients can figure out whether sin(col) will work
> > or if col || 'foo' will likely be a good idea..
> >
> > Additionally, TAP_SCHEMA is (presumably) shared between different
> > languages on the same TAP server (I, for one, am tempted to allow in
> > subsets of postgres, e.g., for WITH).  It hence would seem unwise to
> > hard-code ADQL types in TAP_SCHEMA, in particular if they aren't
> > really ADQL types in the first place.
> >
> > Thus, I'd argue we should drop the prefixes and just use "generic"
> > SQL types (while not disallowing stuffing any old junk in there
> > ("NETMASK", "BOOLEAN"), as currently consumers of this are humans
> > anyway).
>
> I mostly agree, though as it stands it doesn't address Pat's requirements.
> Based on the state of the argument so far, I'd suggest:
>
>    - If possible, put the db type ("DOUBLE", "INTEGER" etc)
>      as shown in the last column of the table in TAP 2.5
>    - Don't prefix those types with "adql:"
>    - But you can put anything else in there if you want, and if
>      you'd like to slap some characters before a colon at the front,
>      go ahead
>
> From the validation point of view, I shouldn't issue anything more
> aggressive than a WARNING if I see something in those columns
> which has an unrecognised syntax or which is apparently incompatible
> with the data type declared at the /tables endpoint.
>
> 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/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ivoa.net/pipermail/dal/attachments/20140605/03b45dae/attachment.html>