Reconsider your data model if you are really going to compare two columns which obviously have the same content and meaning but are of different data type...
:-) Patrick
Eddie Awad
· 2 years ago
@Patrick: Sure, if you can change the data model, that will be a very good solution. But, sometimes reality hurts and you're stuck with a model that you have no control over. I sometimes do find myself in such a situation, unfortunately, especially when I deal with FlexFields (varchar2 columns) in Oracle EBS.
Patrick Wolf
· 2 years ago
Yeah, reality sometimes is so far way from the "ideal" world :-)
Justin Cave
· 2 years ago
When trying to filter out rows, be aware that there is no guarantee about what order Oracle executes the various conditions. So you might well find that the invalid number error returns down the road when the query plan changes.
Even if you nest the subquery, i.e.
<pre> SELECT t1.col1, t2.col2 FROM (SELECT t.col1 FROM table1 t WHERE filter_out_non_numbers) t1, table2 t2 WHERE t1.col1 = t2.col1 </pre>
there is no guarantee that the inner subquery is logically materialized before the join (and the implicit conversion) happens.
Eddie Awad
· 2 years ago
@Justin: Good points.
One more thing, if the to_char is used in the WHERE clause, that will break the use of indexes which may impact performance. So, a function based index may be a good option here.
All Comments
Reconsider your data model if you are really going to compare two columns which obviously have the same content and meaning but are of different data type...
:-)
Patrick
Even if you nest the subquery, i.e.
<pre>
SELECT t1.col1, t2.col2
FROM (SELECT t.col1
FROM table1 t
WHERE filter_out_non_numbers) t1,
table2 t2
WHERE t1.col1 = t2.col1
</pre>
there is no guarantee that the inner subquery is logically materialized before the join (and the implicit conversion) happens.
One more thing, if the to_char is used in the WHERE clause, that will break the use of indexes which may impact performance. So, a function based index may be a good option here.