TAP 1.1, MAXREC and TOP
Markus Demleitner
msdemlei at ari.uni-heidelberg.de
Mon Aug 31 11:15:32 CEST 2015
Dear DAL,
I believe we should use the opportunity of TAP 1.1. to clarify the
interaction of TAP's MAXREC and ADQL's TOP.
True, TAP is more general than ADQL, but the large majority of TAP
queries are ADQL, and differing behaviours between various servers
are an annoyance.
Essentially, the question is: What's to happen when MAXREC=200 is
specified in a query parameter, and there's a TOP 4000 clause in
QUERY?
There certainly are good arguments to say "use the minimum of both
numbers", but I'd argue for "use what's in the query", as that
probably is most directly what the user wrote. You see, at least in
TOPCAT, and I suspect in other clients, too, MAXREC is a bit out of
the focus of the user interface but preset. It's unlikely that users
having wrote a TOP clause differing from MAXREC actually set
MAXREC conciously.
A slight drawback might be that, to figure out the metadata-only case
of MAXREC=0 (or SELECT TOP 0), a service needs to parse the query.
It would have to do that anyway, though, to produce the metadata
requested, so I don't think that's a major problem.
If we can reach an agreement on this, I'd say we should change sect
2.7.5 of the current 1.1 draft. Where there's now
The MAXREC parameter and its effect on the query result is fully
described in [std:DALI]. If the result set is truncated in this
fashion, it must include an overflow indicator as specified in
section XREF.
I propose we should write
TAP supports the MAXREC parameter as specified in [std:DALI],
version 1.0, where what is limited is the number of database rows
in the first result table; where TAP jobs produce multiple tables,
the row counts of the other tables are not included.
However, many query languages transported by TAP have
their own mechanisms for limiting the number of records to be
returned; for instance, in ADQL there is the <set_limit> production
("TOP n"). When a query gives both MAXREC and such a
language-specific row limit, the language-specific limit overrides
MAXREC (as it was presumably directly entered by the user). When a
query gives no MAXREC but a language-specific set limit, services
SHOULD (next major version: MUST) behave as if MAXREC were set to
the language-specific set limit.
If a result is truncated due to MAXREC (or an equivalent
mechanism), the query response must include an overflow indicator
are specifiec in sectin <ref>
What does everyone think?
Cheers,
Markus
More information about the dal
mailing list