TAP RFC [MTIME]
patrick.dowler at nrc-cnrc.gc.ca
Thu Sep 17 09:32:31 PDT 2009
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
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?
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
More information about the dal