<div dir="ltr">Hi all,<div>leaving out the scoring topic related to TOP in SSAP, I wouldn't consider the ADQL.TOP something to compare to to the TOP in SSAP.</div><div>Dave neatly pointed out the TAP perspective for the MAXREC + TOP layering, that comes from two different interfaces, MAXREC for TAP, TOP inside ADQL.</div><div>In SSAP I think the user expects the same behavior, but the query part is directly internal to the SSAP "parametric query language".</div><div>If (when?) a general PQL for IVOA comes up (again) we can discuss whether for simple protocols it is better to change TOP into BEST (or whatever) not to create confusion to users, or whether the PQL should keep as much as possible the reserved words coming from the SQL experience of ADQL&TAP.</div><div><br></div><div>Cheers,</div><div> Marco</div><div><br></div><div>ps - BTW, TOP was brought up also in Banff (IIRC) inside the pagination of results...maybe this is something to keep in mind when there will be a need to reuse/redefine it</div></div><div class="gmail_extra"><br><div class="gmail_quote">2015-04-28 1:56 GMT+02:00 Douglas Tody <span dir="ltr"><<a href="mailto:dtody@nrao.edu" target="_blank">dtody@nrao.edu</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Yes; basically, TOP is another query parameter, whereas MAXREC controls<br>
the output processing, for any type of service and any query language.<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
On Tue, 28 Apr 2015, Dave Morris wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
On 2015-04-27 16:03, Markus Demleitner wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
And regarding Walter's interjection:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I thought that the difference between MAXREC and TOP is that MAXREC<br>
requires an overflow indicator, while TOP would prohibit it.<br>
</blockquote>
<br>
Interesting thought -- is it intended to work this way? [it doesn't<br>
in DaCHS, and a quick search in the 1.1 specs didn't give me anything<br>
pointing in that direction]<br>
<br>
</blockquote>
<br>
For a TAP service.<br>
<br>
I don't know what the specifications say, but as an end user, I would expect that the server returns the lesser of the two, TOP or MAXREC.<br>
<br>
However, if MAXREC caused the truncation, then that would be an overflow, if TOP cause the truncation, then it would not.<br>
<br>
If TOP > MAXREC, then return MAXREC rows and flag an overflow. Which means this probably would hit MAXREC and return an overflow :<br>
<br>
SELECT TOP 1000000000000000000 * FROM table<br>
<br>
If TOP < MAXREC, then return TOP rows and no overflow. So I would not expect to get an overflow for this :<br>
<br>
SELECT TOP 1 * FROM table<br>
<br>
I would probably expect the other services to behave in a similar manner.<br>
<br>
Hope this helps,<br>
Dave<br>
<br>
--------<br>
Dave Morris<br>
Software Developer<br>
Wide Field Astronomy Unit<br>
Institute for Astronomy<br>
University of Edinburgh<br>
--------<br>
<br>
</blockquote>
</div></div></blockquote></div><br></div>