TAP RFC [MTIME]

[Doug Tody]

On Thu, 17 Sep 2009, Patrick Dowler wrote:

> 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 already noted, this metadata is useful even with an ADQL query since
a smart client can use it in various ways - we already have plenty of use
cases where we do this.

> 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?

I say lets keep it and not reverse a decision we already made over
a year ago which supports current practice in actual archives and
client tools.  I agree that the name could be changed to avoid
confusion with DBMS terminology (primary keys).

 	- Doug