<p dir="ltr">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. </p>
<p dir="ltr"> - Arnold </p>
<div class="gmail_quote">On Sep 1, 2015 7:44 AM, "Markus Demleitner" <<a href="mailto:msdemlei@ari.uni-heidelberg.de">msdemlei@ari.uni-heidelberg.de</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Mon, Aug 31, 2015 at 12:37:06PM -0700, Patrick Dowler wrote:<br>
> On 31/08/15 02:15 AM, Markus Demleitner wrote:<br>
> >Essentially, the question is: What's to happen when MAXREC=200 is<br>
> >specified in a query parameter, and there's a TOP 4000 clause in<br>
> >QUERY?<br>
[...]<br>
> From the point of view of the query capturing the query in the<br>
> abstract, some of those contain limits and in that case I favour<br>
> using TOP to keep the definition of the result set in one place.<br>
><br>
> MAXREC - client-server agreement on size of output, with overflow indicator<br>
> when applicable<br>
> TOP - logical limit on membership in the row set<br>
<br>
Well -- even though I'd not say this conclusion is inevitable and I<br>
still believe we'd be doing our users a favour if TOP overrode<br>
MAXREC, I'm fine with it as long as all servers behave identially.<br>
<br>
So -- can we put this "MAXREC clobbers TOP" into the spec? This<br>
could be then, in 2.7.5<br>
<br>
TAP supports the MAXREC parameter as specified in [std:DALI],<br>
version 1.0, where what is limited is the number of database rows<br>
in the first result table; where TAP jobs produce multiple tables,<br>
the row counts of the other tables are not included.<br>
<br>
Where query languages transported by TAP have<br>
their own mechanisms for limiting the number of records to be<br>
returned (e.g., ADQL's <set_limit> production,"TOP n"), MAXREC<br>
still gives the maximum number of rows. In effect, the number of<br>
rows returned is the minimum of MAXREC and the language-specific<br>
set limit.<br>
<br>
If a result is truncated due to MAXREC (or an equivalent<br>
mechanism), the query response must include an overflow indicator<br>
are specifiec in sectin <ref><br>
<br>
<br>
<br>
And, since Walter asked: yes, the designers of ADQL should probably<br>
have forseen that there'd be a parameter-level set limit and left out<br>
TOP to avoid having two things for the same purpose. They didn't,<br>
and I suspect the annoyance of keeping it (to users and server<br>
operators) is quite a bit lower than the annoyance of removing it at<br>
this point, when there's TOP xy queries all over the place.<br>
Hence, I'm afraid we can't do much better than at least clearly<br>
document the interaction between the two.<br>
<br>
<br>
And, given that, I'd wish clients would not pass in MAXREC by<br>
default. Mark... Do you think you could have the Max Row combo in<br>
TOPCAT default to empty?<br>
<br>
Cheers,<br>
<br>
Markus<br>
<br>
</blockquote></div>