Apress.Expert.Oracle.Database.Architecture.9i.and.10g.Programming.Techniques.and.Solutions.Sep.2005

CHAPTER 12 ■ DATATYPES 503
ops$tkyte@ORA10GR1> create table t ( raw_data raw(16) );
Table created.
The RAW type is much like the VARCHAR2 type in terms of storage on disk. The RAW type is a
variable-length binary string, meaning that the table T just created, for example, may store
anywhere from 0 to 16 bytes of binary data. It is not padded out like the CHAR type.
When dealing with RAW data, you will likely find it being implicitly converted to a VARCHAR2
type—that is, many tools such as SQL*Plus will not display the RAW data directly, but will convert
it to a hexadecimal format for display. In the following example, we create some binary
data in our table using SYS_GUID(), a built-in function that returns a 16-byte RAW string that is
globally unique (GUID stands for globally unique identifier):
ops$tkyte@ORA10GR1> insert into t values ( sys_guid() );
1 row created.
ops$tkyte@ORA10GR1> select * from t;
RAW_DATA
--------------------------------
FD1EB03D3718077BE030007F01002FF5
You can immediately note two things here. First, the RAW data looks like a character string.
That is just how SQL*Plus retrieved and printed it, and that is not how it is stored on disk.
SQL*Plus cannot print arbitrary binary data on your screen, as that could have serious side
effects on the display. Remember that binary data may include control characters such as a
carriage return or linefeed, or maybe a Ctrl+G character that would cause your terminal to
“beep.”
Second, the RAW data looks much larger than 16 bytes—in fact, in this example, you can
see 32 characters. This is due to the fact that every binary byte takes two hexadecimal characters
to display. The stored RAW data is really 16 bytes in length, and you can see this using the
Oracle DUMP function. Here, I am “dumping” the value of the binary string and using the
optional parameter to specify the base that should be used when displaying the value of each
byte. I am using base 16, so we can compare the results of dump with the previous string:
ops$tkyte@ORA10GR1> select dump(raw_data,16) from t;
DUMP(RAW_DATA,16)
-------------------------------------------------------------------------------
Typ=23 Len=16: fd,1e,b0,3d,37,18,7,7b,e0,30,0,7f,1,0,2f,f5
So, DUMP shows us this binary string is in fact 16 bytes long (LEN=16) and displays the
binary data byte by byte. As we can see, this dump display matches up with the implicit conversion
performed when SQL*Plus fetched the RAW data into a string. This implicit conversion
goes the other direction as well:
ops$tkyte@ORA10GR1> insert into t values ( 'abcdef' );
1 row created.
That did not insert the string abcdef, but rather a 3-byte RAW with the bytes AB, CD, EF, or
in decimal with the bytes 171, 205, 239. If you attempt to use a string that does not consist of
valid hex characters, you will receive an error message: