datatype values in TAP_SCHEMA.columns

[Mark Taylor]

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/