> > Every aggregation function is at least second order: a function that
> > applies a function to the set. So for MIN the function is 'less than',
> > for SUM() the function is 'plus' and so on. In Andl aggregation
> > functions are provided by fold(), which takes a function as an
> > argument.
>
> Actually, MIN still is fundamentally a first-order itself. The dyadic
> function call "x min y" returns either x or y depending on how they
compare.
> The list form is then repeated application of the binary min(). This is
> directly comparable to your example of list plus/sum which is repetiti
On Fri, 20 May 2016 14:17:25 +1000
"dandl" wrote:
> Every aggregation function is at least second order: a function that
> applies a function to the set. So for MIN the function is 'less
> than', for SUM() the function is 'plus' and so on. In Andl
> aggregation functions are provided by fold(), w
> That's an interesting perspective. If you're dealing with genuine sets,
and
> you define your language in terms of second-order operations, then
something
> like LIMIT could be included. Would have to be, I guess.
Every aggregation function is at least second order: a function that applies
a f
On 2016-05-19 9:17 PM, dandl wrote:
> Every aggregation function is at least second order: a function that applies
> a function to the set. So for MIN the function is 'less than', for SUM() the
> function is 'plus' and so on. In Andl aggregation functions are provided by
> fold(), which takes a fun
On Thu, 19 May 2016 10:29:48 +1000
"dandl" wrote:
> > Restriction is applied to the values of the tuple. The number of
> > tuples is not a value of the tuple.
>
> No, I can't agree. Restriction is a membership test, a function on
> members: should this tuple be included in the result set or not
> Restriction is applied to the values of the tuple. The number of tuples
is
> not a value of the tuple.
No, I can't agree. Restriction is a membership test, a function on members:
should this tuple be included in the result set or not? Cardinality of a set
is a second order function on the membe
> > 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
On Wed, 18 May 2016 20:29:26 +1000
"dandl" wrote:
> > 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
On Wed, 18 May 2016 10:41:21 +1000
"dandl" wrote:
> > You lost me at "subset S of N tuples". Which relational operator
> > takes N as an argument?
>
> Restriction determines whether a tuple should be included or not; you
> also need cardinality and less than (for comparing members).
Restrictio
> Or we'll answer my original question by breaking down one of the above two
> options. The documentation for the implementation may simply say that the
> order will be consistent in any one database connection, without ever
saying
> what the order will be.
This is perfectly consistent with Sqlit
> On 18 May 2016, at 02:41, dandl wrote:
>
> Then you are mistaken.
> 1. Consider the following set S of integers: 1,3,5,7,42,99,83,11.
> 2. Divide it into two subsets such that S1 is of size 3 and all members of
> S1 are larger than those in S2.
>
> A sort is unnecessary -- there are many alg
> The "problem" is to produce 3 rows where, relationally, the only answers
have
> 2 or 4 rows. There is no right answer to the problem because there is no
> answer to the problem.
Which is what I said. The solution with 3 rows is unambiguous. You either
resolve this the way the standard does by m
> I am quite certain nevertheless that LIMIT has no relational basis.
> Nothing based on Order By could.
Then you are mistaken.
1. Consider the following set S of integers: 1,3,5,7,42,99,83,11.
2. Divide it into two subsets such that S1 is of size 3 and all members of
S1 are larger than those i
On 2016-05-18 2:19 AM, Stefan Evert wrote:
>> On 18 May 2016, at 02:41, dandl wrote:
>>
>> Then you are mistaken.
>> 1. Consider the following set S of integers: 1,3,5,7,42,99,83,11.
>> 2. Divide it into two subsets such that S1 is of size 3 and all members of
>> S1 are larger than those in S2.
>>
On 18 May 2016, at 2:05am, dandl wrote:
>> The "problem" is to produce 3 rows where, relationally, the only answers
> have
>> 2 or 4 rows. There is no right answer to the problem because there is no
>> answer to the problem.
>
> Which is what I said. The solution with 3 rows is unambiguous. Yo
On Tue, 17 May 2016 11:09:53 +1000
"dandl" wrote:
> Any disagreement so far?
Full agreement; your description is perfectly sound.
I am quite certain nevertheless that LIMIT has no relational basis.
Nothing based on Order By could. And I'll try to clear up what I meant
by a cursor.
> So th
On Tue, 17 May 2016 11:09:53 +1000
"dandl" wrote:
> > I'll invent here and now to replace LIMIT: nth().
>
> The issue is find the "top N". This does not solve the problem.
nth() does find "top N". For any query, nth(c, N) returns N rows. It
also exposes the arbitrariness of LIMIT. To use
> > > > first second
> > > > - --
> > > > MarkSpark
> > > > Emily Spark
> > > > MarySoper
> > > > Brian Soper
> > > >
> > > > SELECT first,second FROM members ORDER BY second LIMIT 3
>
> First, hat tip to Simon for providing a motivating example. :-)
>
> The question illu
> > All true. But it brings up a question. Suppose the following:
> >
> > first second
> > - --
> > MarkSpark
> > Emily Spark
> > MarySoper
> > Brian Soper
> >
> > SELECT first,second FROM members ORDER BY second LIMIT 3
> >
> I think a proper solut
On 16 May 2016, at 5:29am, Darren Duncan wrote:
> On 2016-05-15 12:35 AM, Simon Slavin wrote:
>
>> firstsecond
>> ---
>> Mark Spark
>> EmilySpark
>> Mary Soper
>> BrianSoper
>>
>> SELECT first,second FROM members ORDER BY second LIMIT 3
>
> I think a pr
On Mon, 16 May 2016 16:17:35 +1000
"dandl" wrote:
> > > All true. But it brings up a question. Suppose the following:
> > >
> > > first second
> > > - --
> > > Mark Spark
> > > Emily Spark
> > > Mary Soper
> > > Brian Soper
> > >
> > > SELECT first,second FROM
On 2016/05/16 8:17 AM, dandl wrote:
>> all rows are returned or zero rows are returned. Thus the result is
>> deterministic.
>>
>> Whether returning above or below the limit is done, is a separate thing to
>> decide, though I suggest returning above is better.
> I would say that this is an inval
.
> -Original Message-
> From: sqlite-users-bounces at mailinglists.sqlite.org [mailto:sqlite-users-
> bounces at mailinglists.sqlite.org] On Behalf Of Darren Duncan
> Sent: Sunday, 15 May, 2016 22:30
> To: SQLite mailing list
> Subject: Re: [sqlite] Sqlite incompatibility wit
On 2016-05-15 11:17 PM, dandl wrote:
>>> All true. But it brings up a question. Suppose the following:
>>>
>>> first second
>>> - --
>>> MarkSpark
>>> Emily Spark
>>> MarySoper
>>> Brian Soper
>>>
>>> SELECT first,second FROM members ORDER BY second
On 2016-05-15 10:50 PM, J Decker wrote:
> On Sun, May 15, 2016 at 10:02 PM, Darren Duncan
> wrote:
>> On 2016-05-15 9:56 PM, J Decker wrote:
>>>
>>> On Sun, May 15, 2016 at 9:29 PM, Darren Duncan
>>> wrote:
On 2016-05-15 12:35 AM, Simon Slavin wrote:
>
> All true. But it bring
On Sun, May 15, 2016 at 10:02 PM, Darren Duncan
wrote:
> On 2016-05-15 9:56 PM, J Decker wrote:
>>
>> On Sun, May 15, 2016 at 9:29 PM, Darren Duncan
>> wrote:
>>>
>>> On 2016-05-15 12:35 AM, Simon Slavin wrote:
All true. But it brings up a question. Suppose the following:
>
On 2016-05-15 9:56 PM, J Decker wrote:
> On Sun, May 15, 2016 at 9:29 PM, Darren Duncan
> wrote:
>> On 2016-05-15 12:35 AM, Simon Slavin wrote:
>>>
>>> All true. But it brings up a question. Suppose the following:
>>>
>>> first second
>>> - --
>>> MarkSpark
>>> Emily Spark
>>>
On Sun, May 15, 2016 at 9:29 PM, Darren Duncan
wrote:
> On 2016-05-15 12:35 AM, Simon Slavin wrote:
>>
>> On 15 May 2016, at 6:04am, Darren Duncan wrote:
>>
>>> You seem to be forgetting the fact that LIMIT/OFFSET is not its own
>>> clause, rather it is an extension to the ORDER BY clause and on
On 2016-05-15 12:35 AM, Simon Slavin wrote:
> On 15 May 2016, at 6:04am, Darren Duncan wrote:
>
>> You seem to be forgetting the fact that LIMIT/OFFSET is not its own clause,
>> rather it is an extension to the ORDER BY clause and only has meaning within
>> the context of the ORDER BY it is part
> I suggest the reason LIMIT hasn't been standardized is that it's contrary
to
> the fundamental idea that rows in a table have no meaningful order. SQL
> doesn't honor relational theory with complete
> fidelity, but at least that horse is still in the barn.
Point 1: I think you'll find plenty of
On 15 May 2016, at 6:04am, Darren Duncan wrote:
> You seem to be forgetting the fact that LIMIT/OFFSET is not its own clause,
> rather it is an extension to the ORDER BY clause and only has meaning within
> the context of the ORDER BY it is part of.
All true. But it brings up a question. Su
Someone should wake the SQL standard committee and nominate sqlite
being the broadest used so should fill some gaps in specification with
it. :) and conversely blame the others for their incompatibility :)
On 2016-05-14 11:30 AM, James K. Lowden wrote:
> I suggest the reason LIMIT hasn't been standardized is that it's
> contrary to the fundamental idea that rows in a table have no
> meaningful order. SQL doesn't honor relational theory with complete
> fidelity, but at least that horse is still in th
On Fri, 13 May 2016 15:13:01 +0100
Simon Slavin wrote:
> On 13 May 2016, at 3:07pm, dandl wrote:
>
> > I have no deep knowledge of standard SQL.
>
> I used to know SQL92 very well. There's no facility for doing
> anything like LIMIT or OFFSET in it. You had to use your programming
> language
Saturday, 14 May 2016 6:28 AM
> To: SQLite mailing list
> Subject: Re: [sqlite] Sqlite incompatibility with Postgres
>
> On 2016-05-13 7:07 AM, dandl wrote:
> > I checked a copy of the
> > 2003 standard and there doesn't seem to be anything similar. I don't
&g
> It would also be very minor to add "UNION -1" as a synonym for "UNION
ALL",
> but "being minor" is not an argument for doing so.
> While the mentorship of Postgres is undoubted, there is/was never a drive,
> nor a need for full (or even partial) compatibility with "Postgres" per
se,
> mostly care
On Fri, May 13, 2016 at 7:33 PM, wrote:
> Derby:
> SELECT * FROM schemaTableName FETCH FIRST ROW ONLY
> [...]
> Oracle:
> SELECT * FROM schemaTableName WHERE ROWNUM=1
Oracle 12c added FETCH FIRST ROW ONLY too. --DD
https://oracle-base.com/articles/12c/row-limiting-clause-for-top-n-queries-12cr1
On 13 May 2016, at 3:07pm, dandl wrote:
> I have no deep knowledge of standard SQL.
I used to know SQL92 very well. There's no facility for doing anything like
LIMIT or OFFSET in it. You had to use your programming language to work your
way through all the results and skip the ones you didn
> I used to know SQL92 very well. There's no facility for doing anything
> like LIMIT or OFFSET in it. You had to use your programming language to
> work your way through all the results and skip the ones you didn't want.
>
> It is because there was no standard for this that each of the big SQL
>
On 2016-05-13 7:07 AM, dandl wrote:
> I checked a copy of the
> 2003 standard and there doesn't seem to be anything similar. I don't have
> anything later.
Whitemarsh is your friend.
http://www.wiscorp.com/SQLStandards.html
They have a copy of the SQL 2011/2 draft there, under the erroneous titl
> > Richard Hipp seems to be on record as saying:
> > "SQLite can be thought of as a derivative of PostgreSQL. SQLite was
> > originally written from PostgreSQL 6.5 documentation, and the SQLite
> > developers still use PostgreSQL as a reference platform to verify that
> > SQLite is working correct
On 2016/05/13 5:24 AM, dandl wrote:
>>> Richard Hipp seems to be on record as saying:
>>> "SQLite can be thought of as a derivative of PostgreSQL. SQLite was
>>> originally written from PostgreSQL 6.5 documentation, and the SQLite
>>> developers still use PostgreSQL as a reference platform to ver
> > Sqlite accepts (but Postgres does not):
> > LIMIT -1 OFFSET nnn
> > LIMIT -1
> >
> > These all have the same meaning of no limit, but there is no common
> > ground in the syntax.
>
> Yes and Yes. Documented behaviour. There are some strange situations if
the
> two clauses can't both be satis
Fair enough.
On Thu, May 12, 2016 at 9:24 PM, dandl wrote:
> > > Richard Hipp seems to be on record as saying:
> > > "SQLite can be thought of as a derivative of PostgreSQL. SQLite was
> > > originally written from PostgreSQL 6.5 documentation, and the SQLite
> > > developers still use PostgreSQ
It's a minor point, but can someone confirm that:
Postgres accepts (but Sqlite does not)
LIMIT ALL
LIMIT ALL OFFSET nnn
OFFSET nnn
Sqlite accepts (but Postgres does not):
LIMIT -1 OFFSET nnn
LIMIT -1
These all have the same meaning of no limit, but there is no common ground
in the syntax.
Regar
On Thu, May 12, 2016 at 6:07 PM, dandl wrote:
> > > Sqlite accepts (but Postgres does not):
> > > LIMIT -1 OFFSET nnn
> > > LIMIT -1
> > >
> > > These all have the same meaning of no limit, but there is no common
> > > ground in the syntax.
> >
> > Yes and Yes. Documented behaviour. There are s
On 12 May 2016, at 11:24am, dandl wrote:
> Sqlite accepts (but Postgres does not):
> LIMIT -1 OFFSET nnn
> LIMIT -1
>
> These all have the same meaning of no limit, but there is no common ground
> in the syntax.
Yes and Yes. Documented behaviour. There are some strange situations if the
two
> It's a minor point, but can someone confirm that:
>
> Postgres accepts (but Sqlite does not)
> LIMIT ALL
> LIMIT ALL OFFSET nnn
> OFFSET nnn
>
> Sqlite accepts (but Postgres does not):
> LIMIT -1 OFFSET nnn
> LIMIT -1
>
> These all have the same meaning of no limit, but there is no common
> groun
49 matches
Mail list logo
