Re: [sqlite] Should the next release be 3.5.4 or 3.6.0?
3.5.4 -- pozdrawiam / regards Zbigniew Baniewski - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] Should the next release be 3.5.4 or 3.6.0?
Dr Gerard Hammond wrote: (2) If an ORDER BY term is a simple identifer (like "x", not "x.y" and not "x.y.z") and if there if the k-th column uses that same identifer as an AS alias, the sort by the k-th column. CREATE TABLE a(x,y); INSERT INTO a VALUES(1,8); INSERT INTO a VALUES(9,2); SELECT x AS y FROM a ORDER BY y; I don't understand. If I say "ORDER BY y" aren't I saying sort the result set based on the column " as y" of the result set, not the table "a.y"? ie they should come out y 9 1 Your description is correct, but your output is in the wrong order. The default sort order is ascending so the 9 will sort after the 1. Y 1 9 Dennis Cote - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] Should the next release be 3.5.4 or 3.6.0?
My question first is can this fix be rolled into a group of related fixes thus creating a service patch? If not then my opinion is 3.5.4. If you can roll it in with 3 - 10 easy fixes call it 3.6.0. Just an opinion though. I am waiting for 4.0, like it is Xmas Eve... On Dec 13, 2007, at 10:40 AM, [EMAIL PROTECTED] wrote: Ticket number #2822 http://www.sqlite.org/cvstrac/tktview?tn=2822 has provoked extensive changes to the way SQLite handles ORDER BY clauses. The current algorithm goes like this: (1) If an ORDER BY term is a constant integer k then sort by the k-th column of the result set. (2) If an ORDER BY term is a simple identifer (like "x", not "x.y" and not "x.y.z") and if there if the k-th column uses that same identifer as an AS alias, the sort by the k-th column. (3) Otherwise, evaluate the expression which is in the ORDER BY term and sort by the resulting value. For a compound query, the expression in step (3) must exactly match one of the result columns. Also, the three steps are attempted first on the left-most SELECT. If there is a match, the process stops there. If no match is found, the next SELECT to the right is tried. This repeats as necessary until a match is found or until you run out of SELECT statement in which case there is an error. This algorithm differs from all prior versions of SQLite (1.0.0 through 3.5.3) by the addition of step (2). Adding step (2) brings SQLite much closer to the SQL standard. I believe that SQLite is now a superset of the SQL standard. SQL has no concept of step (3). And in a compound query, SQL only looks at the left-most SELECT and does not fail over to SELECT statements to the right looking for a match. But these changes can be considered extensions. The revised algorithm is mostly compatible with the way SQLite has always operated before. But there are a few obscure corner cases where there is a difference. An example of the difference is the following: CREATE TABLE a(x,y); INSERT INTO a VALUES(1,8); INSERT INTO a VALUES(9,2); SELECT x AS y FROM a ORDER BY y; In older versions of SQLite, the SELECT statement above would return 9, 1 since the ORDER BY term evaluated to the expression a.y by rule (3) In the next release, because of the addition of rule (2) above, the result will be 1, 9. My question to the community is this: Are these differences sufficient to justify going with version 3.6.0 in the next release? Or can we call the change a "bug fix" and number the next release 3.5.4? Other information to consider: * We do not have a lot of time to debate the merits of this change since we need to get out a release to fix critical bug #2832. * We have taken no steps toward fixing GROUP BY. If I got ORDER BY wrong, I'm guessing GROUP BY is wrong too. Thanks for your input. -- D. Richard Hipp <[EMAIL PROTECTED]> - To unsubscribe, send email to [EMAIL PROTECTED] - - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] Should the next release be 3.5.4 or 3.6.0?
Trey Mack wrote: 3.6.0 in the next release? Or can we call the change a "bug fix" and number the next release 3.5.4? I guess I'm in the minority, but I'd find a change in the meaning of my queries surprising in a bug fix release. That sounds like a 3.6 to me. You may be in the minority, but you're not alone. +1. And I agree, this is a 3.6.0 kind of release. Bob - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] Should the next release be 3.5.4 or 3.6.0?
3.6.0 in the next release? Or can we call the change a "bug fix" and number the next release 3.5.4? I guess I'm in the minority, but I'd find a change in the meaning of my queries surprising in a bug fix release. That sounds like a 3.6 to me. You may be in the minority, but you're not alone. +1. - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] Should the next release be 3.5.4 or 3.6.0?
On Dec 14, 2007 12:35 AM, Steven Fisher <[EMAIL PROTECTED]> wrote: > On 13-Dec-2007, at 8:40 AM, [EMAIL PROTECTED] wrote: > > > My question to the community is this: Are these > > differences sufficient to justify going with version > > 3.6.0 in the next release? Or can we call the change > > a "bug fix" and number the next release 3.5.4? > > I guess I'm in the minority, but I'd find a change in the meaning of > my queries surprising in a bug fix release. That sounds like a 3.6 to > me. Well, I agree with you. It just seems the right thing to do, and version numbers are cheap. Regards, ~Nuno Lucas - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] Should the next release be 3.5.4 or 3.6.0?
On 13-Dec-2007, at 8:40 AM, [EMAIL PROTECTED] wrote: My question to the community is this: Are these differences sufficient to justify going with version 3.6.0 in the next release? Or can we call the change a "bug fix" and number the next release 3.5.4? I guess I'm in the minority, but I'd find a change in the meaning of my queries surprising in a bug fix release. That sounds like a 3.6 to me. - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] Should the next release be 3.5.4 or 3.6.0?
On 14/12/2007, at 3:40 AM, [EMAIL PROTECTED] wrote: Ticket number #2822 http://www.sqlite.org/cvstrac/tktview?tn=2822 (2) If an ORDER BY term is a simple identifer (like "x", not "x.y" and not "x.y.z") and if there if the k-th column uses that same identifer as an AS alias, the sort by the k-th column. CREATE TABLE a(x,y); INSERT INTO a VALUES(1,8); INSERT INTO a VALUES(9,2); SELECT x AS y FROM a ORDER BY y; In older versions of SQLite, the SELECT statement above would return 9, 1 since the ORDER BY term evaluated to the expression a.y by rule (3) In the next release, because of the addition of rule (2) above, the result will be 1, 9. I don't understand. If I say "ORDER BY y" aren't I saying sort the result set based on the column " as y" of the result set, not the table "a.y"? ie they should come out y 9 1 That's what (2) says to me Cheers. -- Dr Gerard Hammond http://www.macsos.com.au Cheers. -- Dr Gerard Hammond http://www.macsos.com.au Cheers. -- Dr Gerard Hammond Garvan Institute of Medical Research - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] Should the next release be 3.5.4 or 3.6.0?
[EMAIL PROTECTED] wrote: The current algorithm goes like this: (1) If an ORDER BY term is a constant integer k then sort by the k-th column of the result set. (2) If an ORDER BY term is a simple identifer (like "x", not "x.y" and not "x.y.z") and if there if the k-th column uses that same identifer as an AS alias, the sort by the k-th column. (3) Otherwise, evaluate the expression which is in the ORDER BY term and sort by the resulting value. For a compound query, the expression in step (3) must exactly match one of the result columns. Also, the three steps are attempted first on the left-most SELECT. If there is a match, the process stops there. If no match is found, the next SELECT to the right is tried. This repeats as necessary until a match is found or until you run out of SELECT statement in which case there is an error. This algorithm differs from all prior versions of SQLite (1.0.0 through 3.5.3) by the addition of step (2). Adding step (2) brings SQLite much closer to the SQL standard. I believe that SQLite is now a superset of the SQL standard. SQL has no concept of step (3). I believe it does. It calls such columns extended sort keys. The users result table is extended by adding these columns to produce an intermediate result table which is sorted as usual, and then it removes those columns from the result table that is returned. And in a compound query, SQL only looks at the left-most SELECT and does not fail over to SELECT statements to the right looking for a match. But these changes can be considered extensions. Or failures to produce the required diagnostics. :-) The revised algorithm is mostly compatible with the way SQLite has always operated before. But there are a few obscure corner cases where there is a difference. An example of the difference is the following: CREATE TABLE a(x,y); INSERT INTO a VALUES(1,8); INSERT INTO a VALUES(9,2); SELECT x AS y FROM a ORDER BY y; In older versions of SQLite, the SELECT statement above would return 9, 1 since the ORDER BY term evaluated to the expression a.y by rule (3) In the next release, because of the addition of rule (2) above, the result will be 1, 9. My question to the community is this: Are these differences sufficient to justify going with version 3.6.0 in the next release? Or can we call the change a "bug fix" and number the next release 3.5.4? Other information to consider: * We do not have a lot of time to debate the merits of this change since we need to get out a release to fix critical bug #2832. I would say it is bug fix. The previous versions executed the queries incorrectly. * We have taken no steps toward fixing GROUP BY. If I got ORDER BY wrong, I'm guessing GROUP BY is wrong too. And you should probably have another bug fix version release when these bugs are fixed as well. That's my two cents. Dennis Cote - To unsubscribe, send email to [EMAIL PROTECTED] -
RE: [sqlite] Should the next release be 3.5.4 or 3.6.0?
3.5.4 --- We're Hiring! Seeking a passionate developer to join our team building Flex based products. Position is in the Washington D.C. metro area. If interested contact [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thursday, December 13, 2007 11:41 AM To: sqlite-users@sqlite.org Subject: [sqlite] Should the next release be 3.5.4 or 3.6.0? Ticket number #2822 http://www.sqlite.org/cvstrac/tktview?tn=2822 has provoked extensive changes to the way SQLite handles ORDER BY clauses. The current algorithm goes like this: ... -- D. Richard Hipp <[EMAIL PROTECTED]> - To unsubscribe, send email to [EMAIL PROTECTED] -
RE: [sqlite] Should the next release be 3.5.4 or 3.6.0?
Seems like a 3.5.4 to me Mike - To unsubscribe, send email to [EMAIL PROTECTED] -
RE: [sqlite] Should the next release be 3.5.4 or 3.6.0?
If you suspect "Group By" also may be broken, why not to an interim "bug fix" release and then do the version number change when both "Order By" and "Group By" are fixed? I seem to remember instances where both Order BY and Group By have given me "unexpected" results. But then again, my logical thinking is not on Mr. Spock's level, unfortunately. Fred > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Thursday, December 13, 2007 10:41 AM > To: sqlite-users@sqlite.org > Subject: [sqlite] Should the next release be 3.5.4 or 3.6.0? > > > Ticket number #2822 > > http://www.sqlite.org/cvstrac/tktview?tn=2822 > > has provoked extensive changes to the way SQLite handles > ORDER BY clauses. The current algorithm goes like this: > > >(1) If an ORDER BY term is a constant integer k > then sort by the k-th column of the result set. > >(2) If an ORDER BY term is a simple identifer > (like "x", not "x.y" and not "x.y.z") and if > there if the k-th column uses that same identifer > as an AS alias, the sort by the k-th column. > >(3) Otherwise, evaluate the expression which is > in the ORDER BY term and sort by the resulting > value. > > For a compound query, the expression in step (3) must > exactly match one of the result columns. Also, the > three steps are attempted first on the left-most SELECT. > If there is a match, the process stops there. If no > match is found, the next SELECT to the right is tried. > This repeats as necessary until a match is found or > until you run out of SELECT statement in which case there > is an error. > > This algorithm differs from all prior versions of SQLite > (1.0.0 through 3.5.3) by the addition of step (2). > Adding step (2) brings SQLite much closer to the SQL > standard. I believe that SQLite is now a superset of > the SQL standard. SQL has no concept of step (3). And > in a compound query, SQL only looks at the left-most > SELECT and does not fail over to SELECT statements to > the right looking for a match. But these changes can > be considered extensions. > > The revised algorithm is mostly compatible with the > way SQLite has always operated before. But there > are a few obscure corner cases where there is a difference. > An example of the difference is the following: > > CREATE TABLE a(x,y); > INSERT INTO a VALUES(1,8); > INSERT INTO a VALUES(9,2); > > SELECT x AS y FROM a ORDER BY y; > > In older versions of SQLite, the SELECT statement above > would return 9, 1 since the ORDER BY term evaluated to > the expression a.y by rule (3) In the next release, > because of the addition of rule (2) above, the result > will be 1, 9. > > My question to the community is this: Are these > differences sufficient to justify going with version > 3.6.0 in the next release? Or can we call the change > a "bug fix" and number the next release 3.5.4? > > Other information to consider: > >* We do not have a lot of time to debate the merits > of this change since we need to get out a release > to fix critical bug #2832. > >* We have taken no steps toward fixing GROUP BY. > If I got ORDER BY wrong, I'm guessing GROUP BY > is wrong too. > > Thanks for your input. > > -- > D. Richard Hipp <[EMAIL PROTECTED]> > > > -- > --- > To unsubscribe, send email to [EMAIL PROTECTED] > -- > --- > - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] Should the next release be 3.5.4 or 3.6.0?
I'd vote 3.5.4 as well. [EMAIL PROTECTED] wrote: Ticket number #2822 http://www.sqlite.org/cvstrac/tktview?tn=2822 has provoked extensive changes to the way SQLite handles ORDER BY clauses. The current algorithm goes like this: (1) If an ORDER BY term is a constant integer k then sort by the k-th column of the result set. (2) If an ORDER BY term is a simple identifer (like "x", not "x.y" and not "x.y.z") and if there if the k-th column uses that same identifer as an AS alias, the sort by the k-th column. (3) Otherwise, evaluate the expression which is in the ORDER BY term and sort by the resulting value. For a compound query, the expression in step (3) must exactly match one of the result columns. Also, the three steps are attempted first on the left-most SELECT. If there is a match, the process stops there. If no match is found, the next SELECT to the right is tried. This repeats as necessary until a match is found or until you run out of SELECT statement in which case there is an error. This algorithm differs from all prior versions of SQLite (1.0.0 through 3.5.3) by the addition of step (2). Adding step (2) brings SQLite much closer to the SQL standard. I believe that SQLite is now a superset of the SQL standard. SQL has no concept of step (3). And in a compound query, SQL only looks at the left-most SELECT and does not fail over to SELECT statements to the right looking for a match. But these changes can be considered extensions. The revised algorithm is mostly compatible with the way SQLite has always operated before. But there are a few obscure corner cases where there is a difference. An example of the difference is the following: CREATE TABLE a(x,y); INSERT INTO a VALUES(1,8); INSERT INTO a VALUES(9,2); SELECT x AS y FROM a ORDER BY y; In older versions of SQLite, the SELECT statement above would return 9, 1 since the ORDER BY term evaluated to the expression a.y by rule (3) In the next release, because of the addition of rule (2) above, the result will be 1, 9. My question to the community is this: Are these differences sufficient to justify going with version 3.6.0 in the next release? Or can we call the change a "bug fix" and number the next release 3.5.4? Other information to consider: * We do not have a lot of time to debate the merits of this change since we need to get out a release to fix critical bug #2832. * We have taken no steps toward fixing GROUP BY. If I got ORDER BY wrong, I'm guessing GROUP BY is wrong too. Thanks for your input. -- D. Richard Hipp <[EMAIL PROTECTED]> - To unsubscribe, send email to [EMAIL PROTECTED] - - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] Should the next release be 3.5.4 or 3.6.0?
My vote is for 3.5.4. -Jeff - To unsubscribe, send email to [EMAIL PROTECTED] -
