Re: [SPAM] 10gR2 Upgrade .. Watch out
- From: "Daniel W. Fink" <daniel.fink@xxxxxxxxxxxxxx>
- To: oracle-l <oracle-l@xxxxxxxxxxxxx>
- Date: Wed, 27 Dec 2006 20:46:37 -0700
I can only speak for myself, but I was addressing the same subtopic of
the thread - the 'upgrade and default behaviour' issue is in response to
the reply about the changing result set order for GROUP BY and DISTINCT.
Wolfgang's response was about the same time and in response to the same
response as mine.
If the result sets contain the same data, but are returned in a
different order (without an explicit ORDER BY) between releases, I don't
think that is a bug. You simply cannot rely on behaviour that you do not
explicitly code to address.
Now, the 3rd issue the original poster mentioned where two statements
are logically the same but return different results...yeah...that's a bug!
Regards,
Daniel Fink
Nuno Souto wrote:
Quoting Wolfgang Breitling <breitliw@xxxxxxxxxxxxx>:
As far as I'm concerned it merely exposes a bug in your application
code, relying on group by to return the result set in a certain
order. Just because it happens to work in some cases (here Oracle pre
10gR2) does not make it the default behaviour. It was just a side
effect of an implementation detail. The default behaviour is that
without the order by caluse Oracle can return the resultset in any
order it darn well pleases, including in the group by order, but it
doesn't have to. And Oracle warned all along not to rely on it.
as much as I might agree with this, the simple fact
is that in the given example "a=20" doesn't work but
"a between 20 and 20" works. If that is not the
definition of a bug, I don't know what is.
- Follow-Ups:
- Re: [SPAM] 10gR2 Upgrade .. Watch out
- From: Nuno Souto
- References:
- Performance issues after 10gR2 Upgrade.
- From: MVR
- Re: Performance issues after 10gR2 Upgrade.
- From: John Kanagaraj
- 10gR2 Upgrade .. Watch out
- From: GovindanK
- Re: [SPAM] 10gR2 Upgrade .. Watch out
- From: Mark J. Bobak
- Re: [SPAM] 10gR2 Upgrade .. Watch out
- From: GovindanK
- Re: [SPAM] 10gR2 Upgrade .. Watch out
- From: Wolfgang Breitling
- Re: [SPAM] 10gR2 Upgrade .. Watch out
- From: Nuno Souto
Other related posts:
- » Re: [SPAM] 10gR2 Upgrade .. Watch out
- » Re: [SPAM] 10gR2 Upgrade .. Watch out
- » Re: [SPAM] 10gR2 Upgrade .. Watch out
- » Re: [SPAM] 10gR2 Upgrade .. Watch out
- » Re: [SPAM] 10gR2 Upgrade .. Watch out
- » RE: [SPAM] 10gR2 Upgrade .. Watch out
- » Re: [SPAM] 10gR2 Upgrade .. Watch out
- » Re: [SPAM] 10gR2 Upgrade .. Watch out
- » Re: [SPAM] 10gR2 Upgrade .. Watch out
- » Re: [SPAM] 10gR2 Upgrade .. Watch out
- » Re: [SPAM] 10gR2 Upgrade .. Watch out
- » RE: [SPAM] 10gR2 Upgrade .. Watch out
- » RE: [SPAM] 10gR2 Upgrade .. Watch out
Quoting Wolfgang Breitling <breitliw@xxxxxxxxxxxxx>:
As far as I'm concerned it merely exposes a bug in your application code, relying on group by to return the result set in a certain order. Just because it happens to work in some cases (here Oracle pre 10gR2) does not make it the default behaviour. It was just a side effect of an implementation detail. The default behaviour is that without the order by caluse Oracle can return the resultset in any order it darn well pleases, including in the group by order, but it doesn't have to. And Oracle warned all along not to rely on it.
as much as I might agree with this, the simple factis that in the given example "a=20" doesn't work but "a between 20 and 20" works. If that is not the definition of a bug, I don't know what is.
- Re: [SPAM] 10gR2 Upgrade .. Watch out
- From: Nuno Souto
- Performance issues after 10gR2 Upgrade.
- From: MVR
- Re: Performance issues after 10gR2 Upgrade.
- From: John Kanagaraj
- 10gR2 Upgrade .. Watch out
- From: GovindanK
- Re: [SPAM] 10gR2 Upgrade .. Watch out
- From: Mark J. Bobak
- Re: [SPAM] 10gR2 Upgrade .. Watch out
- From: GovindanK
- Re: [SPAM] 10gR2 Upgrade .. Watch out
- From: Wolfgang Breitling
- Re: [SPAM] 10gR2 Upgrade .. Watch out
- From: Nuno Souto