Excellent – thanks for posting that information.

The answer to “how does Oracle” deal with this problem internally is simple – it doesn’t.

I found the function originally while sorting out some client problems with materialized view refresh – so I’ve just re-created one of my test cases with a varchar2(4000) column – this is what happens when the refresh tries to run:

ERROR at line 1:
ORA-12008: error in materialized view refresh path
ORA-01706: user function result value was too large

Thanks for the comment about the seminar – you should have said hello ! My bad luck seems to be over (at least nothing’s gone wrong today, but that’s because a client phoned up last night and postponed a meeting because they had to rebuild their database).

VERSION
-----------------
10.2.0.3.0
select 'fail' from dual where sys_op_map_nonnull(rpad('x',4000))!=sys_op_map_nonnull(null)
                   *
ERROR at line 1:
ORA-01706: user function result value was too large

It appears to work by appending a zero byte (0×00) to whatever the binary representation of its argument is, and by returning hextoraw(‘FF’) in the case of a NULL argument:

SQL>select sys_op_map_nonnull('') somn_null from dual;

SOMN_NULL
----------
FF
SQL>select
  2     dump('A')      dump_a,  sys_op_map_nonnull('A')       somn_a,
  3     dump(chr(255)) dump_ff, sys_op_map_nonnull(chr(255))  somn_ff
  4  from dual;

DUMP_A           SOMN_A     DUMP_FF          SOMN_FF
---------------- ---------- ---------------- ----------
Typ=96 Len=1: 65 4100       Typ=1 Len=1: 255 FF00
SQL>set echo off

I’ve checked this behaviour on values of several types (number, date, varchar2, interval day to second, and a user-defined type).
Of course, sys_op_map_nonnull() needs to append that zero byte to avoid matching a NULL value to the non-NULL value chr(255). Unfortunately, this renders it unusable for columns of type varchar2(4000). It would be interesting to see how Oracle deals with this problem internally :-)

@Jonathan: BTW, I liked your seminar on indexing this week. Hope you got rid of that streak of bad luck :-)

Cheers!

Flado

sys_op_map_nonnull() is designed to return a value that cannot legally appear in the column, so you can’t compare a null with a real column value and get a match by accident.

Regarding sys_op_map_nonnull(old.col1) != sys_op_map_nonnull(new.col1), can’t I use simple NVL function instead?

where sys_op_map_nonnull(c1)=sys_op_map_nonnull('42')

will only use a function-based index on sys_op_map_nonnull(c1) and not a normal one. The result type appears to be RAW (based on HEXTORAW() and RAWTOHEX() calls in the plan predicates)

Cheers!
Flado

I can’t answer your last question – I’ve not yet come across a system where I needed to test the effects of mixing sys_op_map_nonnull() and indexes.

I appreciate succinctness by the way – one of the hardest things about writing is the difficulty of drawing the line between so short you miss the detail and so long that the point gets lost in the detail. I think your comment got the right amount of detail in the right amount of text.

Cheers,
Flado