TAP RFC [MTIME]

[Patrick Dowler]

On Thursday 17 September 2009 03:12:09 Gerard wrote:
>  would propose to remove the "primary" attribute from the column
> metadata? When I do a
>
> select * from SomeTable
>
> I expect all the columns in the table to be returned. if I want fewer I do
> aan explicit select.

I recently (yesterday) entered my own "implementor" comment in the RFC page 
about primary. The first problem  is that primary is a reserved word in most 
RDBMS implementations as it is used to define primary keys.

The main problem is that it only applies to PQL queries because the SELECT 
param is optional and also can take some special values (ALL, PRIMARY, iirc). 
So the "primary" attribute of a column never applies to ADQL or SQL and does 
not necessarily apply to any specific query language that could be used. It is 
away for the service provider to say "these columns are the main ones", but 
the use really ends there in the general case. PQL may/can specify some 
specific behaviour that leverages this attribute, but that is beyond the scope 
of the spec.

As a purely informative piece of metadata, one might ask why a service can't 
say which tables are "primary"? That is often more relevant and informative in 
most real databases

Is it extraneous? Once PQL is defined, one could find this information by doing 
two requests: MAXREC=0&SELECT=ALL and MAXREC=0&SELECT=PRIMARY, for example.


So, the first question is: should we just remove it as extraneous (at least in 
1.0)?

If we keep it, as purely a categorisation hint from the service provider, what 
do we change the column name in TAP_SCHEMA.columns to? 

-- 

Patrick Dowler
Tel/Tél: (250) 363-0044
Canadian Astronomy Data Centre
National Research Council Canada
5071 West Saanich Road
Victoria, BC V9E 2M7

Centre canadien de donnees astronomiques
Conseil national de recherches Canada
5071, chemin West Saanich
Victoria (C.-B.) V9E 2M7