sorry -- couldn 't chime in any earlier in this thread -- what a pity ;-)
I hope I am not just repeating someone else here
parenthesis don 't really impose any processing order;
they just scope the operations in your expressions.
"(A or B) and C " is obviously not the same as "A or (B and C) ",
because they have different truth tables. however, consider the following:
"(A or B) and C " is logically equivalent with "(A and C) or (B and C) "
"A or (B and C) " is logically equivalent with "(A or B) and (A or C) "
so any optimizer would have the right to use the above two transformations
in their attempt to come back with a good plan; that is, the order in which
the predicates A, B, and C are visited is unpredictable and should be 100%
free,
regardless any parentheses.
-- --Original Message-- --
From: oracle-l-bounce@(protected)
[mailto:oracle-l-bounce@(protected)]On Behalf Of Stephen.Lee@(protected)
Sent: Friday, July 16, 2004 15:39
To: oracle-l@(protected)
Subject: RE: to_number question
I think at the heart of the argument that the error should not occur (at
least MY opinion) is that we CAN impose an order on processing so that (A or
B) and C is not the same as A or (B and C), and the RDBMS is not allowed to
throw away the parenthesis and do the processing in any way it chooses.
So at least some folk around here don 't like the fact that it is OK for the
RDBMS to "throw away the parenthesis " in the case of a subquery when an
optimizer that is too smart for its britches can form a logically equivalent
query ... assuming no errors occur.
Maybe it 's a purely pragmatic thing based on what gives the best performance
most of the time. Whatever the reason, I haven 't been convinced that it has
any basis in relational theory. It seems to be nothing more than a
specification.
-- Binary/unsupported file stripped by Ecartis --
-- Type: text/x-vcard
-- File: Lex de Haan.vcf
-- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ------
To unsubscribe send email to: oracle-l-request@(protected)
put 'unsubscribe ' in the subject line.
--
Archives are at http://www.freelists.org/archives/oracle-l/
FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
-- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- --