Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Mailing Lists -> Oracle-L -> RE: to_number question

RE: to_number question

From: Lex de Haan <>
Date: Sat, 17 Jul 2004 12:20:58 +0200
Message-ID: <>

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.

Kind regards,

visit my website at

-----Original Message-----

[]On Behalf Of Stephen.Lee_at_DTAG.Com Sent: Friday, July 16, 2004 15:39
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.

Please see the official ORACLE-L FAQ:

To unsubscribe send email to: put 'unsubscribe' in the subject line.

Archives are at FAQ is at
Received on Sat Jul 17 2004 - 05:17:36 CDT

Original text of this message