TAP 1.1, MAXREC and TOP

[Tom McGlynn (NASA/GSFC Code 660.1)]

I agree with Markus that with TOP specified the results of a query may 
not be
repeatable absent some ordering clause.  I don't think this means that a
query where the number of rows is limited by a TOP clause should have an 
overflow indicated.
The current standard seems pretty clear in 2.7.4 that only queries which 
have been limited
by an explicit or implicit MAXREC should be deemed to overflow. That 
makes sense to me.

Overflow means that the results of the ADQL query were truncated outside 
of the ADQL context.   There are
lots of ways users can control the row count displayed using ADQL -- 
constraints, grouping, top, joins....
The overflow indicator should not be implicated in any of these If a 
user wants to use TOP in ADQL to see
if TOP 400 would overflow, then they should specify TOP 401 and throw 
away the last row after confirming
its existence.

The overflow indicator is a TAP feature that represents truncation by 
TAP, not by ADQL.

     Tom



Markus Demleitner wrote:
> Dear DAL,
>
> On Tue, Sep 01, 2015 at 10:00:12AM -0400, Arnold Rots wrote:
>> Actually, the problem is that TOP is really a form of ORDER BY, combined
>> with implicitly setting MAXREC. It may have been better to cast it as a
>> Boolean.
> Not trying to be too much of a smart aleck, just so people reading
> the archives don't get confused: No, TOP in ADQL does *not* entail
> any ordering of the result sets.  If you want order, you have to use
> ORDER BY.  Consequently, result sets truncated due to TOP (absent
> ORDER BY) are *not* reproducible even when query and table content
> are identical (e.g., a VACUUM on the DB server might change the order
> of rows returned and with MAXREC the choice of rows).
>
> That's my main reason for saying the TAP overflow marker must be
> present regardless of whether the result was truncated due to MAXREC
> or TOP.
>
> Note again that that's different in SSAP, which is probably what
> Arnold was thinking of.  SSAP has a standard parameter called TOP
> that works a bit like MAXREC; in contrast to MAXREC, this TOP does
> say that the n "best" records should be returned.
>
> I fully agree with Arnold that *this* n-best functionality should have
> been provided with a different interface exactly to avoid the
> interference between MAXREC and TOP.  But that's a different story.
>
> Cheers,
>
>           Markus
>