VODataService becoming WD, then PR

[glemson]

HI Pat
Thanks for your reply, it was not clear to me from the current draft how to 
interpret the native SL. Your explanation does take this away as a reason to 
have SQL data types in the metadat. 

It leaves my questions about ADQL (non-)use of data types.
What was the reason that SQL92's <data type> was left out of ADQL?
Same for CAST and create table statements.
Is there the possibility these might one time be introduced?
Related, are the VOTable datatypes rich enough to represent all SQL 
datatypes (I have not done the comparison, has anyone)? 


Thanks 

Gerard 


Patrick Dowler writes: 

> 
> I will say my bit on the DAL list since this is wrt the TAP spec: 
> 
> On 2008-11-19 02:10:34 Gerard wrote:
>> Irrespective of this, according to 3.1.1.2 in
>> http://www.ivoa.net/internal/IVOA/TableAccess/TAP-v0.3.pdf, TAP also has a
>> mode allowing ("MAY") pass-through of native SQL, though it seems it has
>> not been worked out in detail yet.
>> Taking this option seriously might have some impact on the metadata
>> specification.
>> For example one might then want to include a "nativeSQLType" for the column
>> metadata.
>> ALso I suppose the TAP service as a whole could(should) specify the
>> database vendor.
> 
> The idea behind "native SQL" in TAP is that the caller knows the DB schema 
> already (out of band) and wants to tell the service how to interpret the 
> QUERY parameter. That is, tell it to NOT process the query (from ADQL -> 
> SQL). 
> 
> While I am not that excited about this feature as it is explicitly 
> non-portable and non-standard, it is one that some services may want to 
> provide to power-users who need access to something not in ADQL. It is not 
> that we are designing this so much as just saying "if you want to do this, do 
> it this way". Now, any one service could do this anyway and it would not make 
> them non-compliant. However, by adding it to the TAP spec (even loosely) we 
> are reserving some value of the LANG parameter that goes with QUERY so that 
> in future any change/addition to TAP will not step on custom extensions like 
> this. The alternative is that someone might make use of a custom param 
> (NATIVE=true) and then would complain and/or have to do work if some future 
> version of TAP wanted to define that parameter. 
> 
> So, we just want to reserve a value for LANG, recommend (strongly) that people 
> use that for native SQL. After that, this is for power-users who know the 
> schema, so we can (should) stop there... and by stop there I mean stick with 
> only the VOTable data types. This is really to allow people to use features 
> of the DB directly (eg CUBE and ROLLUP in DB2, table-valued functions, and 
> stuff that is not part of ADQL). The service still has to return it in 
> VOTable, so it has to coerce the values into VOTable datatypes. 
> 
> --  
> 
> Patrick Dowler
> Tel/Tél: (250) 363-6914                  | fax/télécopieur: (250) 363-0045
> Canadian Astronomy Data Centre   | Centre canadien de donnees astronomiques
> National Research Council Canada | Conseil national de recherches Canada
> Government of Canada                  | Gouvernement du Canada
> 5071 West Saanich Road               | 5071, chemin West Saanich
> Victoria, BC                                  | Victoria (C.-B.)