TAP 1.1, MAXREC and TOP

[Markus Demleitner]

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