> > Consider this set of integers: 1,3,5,7,42,99,83,11,83,83 > > > > In this case, there is no subset S1 of size 3 that satisfies your > criterion. In an SQL query, the set returned by LIMIT 3 would not be defined > uniquely. > > What you've both said is essentially the point I was trying to make. > > 1. If you want a deterministic portable result for all valid invocations of > LIMIT, you need to either constrain it to use with a totally ordered set (it > would be an error to use it on something with duplicates) in order to > guarantee the number of rows specified in the LIMIT argument, or you need to > possibly return a different number of rows than the LIMIT argument. > > 2. Otherwise, if exactly the number of specified rows must be returned > without other restrictions, then the result is possibly indeterminate.
I agree, with one tiny tweak. The SQL standard already notes that certain queries of this kind are "implementation-dependent". Here is an example. "If the <declare cursor> does not contain an <order by clause>, or contains an <order by clause> that does not specify the order of the rows completely, then the rows of the table have an order that is defined only to the extent that the <order by clause> specifies an order and is otherwise implementation-dependent." So in option 2 the result should be considered "implementation-dependent" and might be deterministic (based on information that is not part of the query) or not. > The options with point 1 are not only deterministic but fully relational. Absolutely. Regards David M Bennett FACS Andl - A New Database Language - andl.org
