3.5.4
--
pozdrawiam / regards
Zbigniew Baniewski
-
To unsubscribe, send email to [EMAIL PROTECTED]
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
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
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
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
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
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
[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
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
Seems like a 3.5.4 to me
Mike
-
To unsubscribe, send email to [EMAIL PROTECTED]
-
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
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
My vote is for 3.5.4.
-Jeff
-
To unsubscribe, send email to [EMAIL PROTECTED]
-
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.
14 matches
Mail list logo
