Why use varchar2 instead of char for package constants? - oracle

Question

Just came across a package which defines a large number of package-global constant strings as such:
DESTINATION_1 CONSTANT VARCHAR2(13) := '515 Pine Lane';
DESTINATION_2 CONSTANT VARCHAR2(18) := '670 Woodhaven Lane';
Is there any benefit to using varchar2 as the datatype for these over char?
Using Oracle 11g release 2.

Answer 1

In general I use VARCHAR2 instead of CHAR for all string variable or constant declarations for the simple reason that VARCHAR2 semantics are more consistent with my expectations. The issue here is that if the developer is less than accurate about his counting of the length of the constant, it will be padded on the right with blanks if declared as CHAR, while it will simply be stored without padding if declared as VARCHAR2. Consider:
DECLARE
strFixed CHAR(20) := 'This is a string';
strVariable VARCHAR2(20) := 'This is a string';
BEGIN
IF strFixed = strVariable THEN
DBMS_OUTPUT.PUT_LINE('Equal');
ELSE
DBMS_OUTPUT.PUT_LINE('Not equal');
END IF;
END;
At first look you might expect this to print "Equal", but it will actually print "Not equal". This is so because strFixed is not stored as 'This is a string'; instead, it's stored as "This is a string ' because CHAR variables are padded on the right with blanks out to the size specified in the variable declaration. Yes, I could have carefully counted the number of characters in the string (there are 17, by the way) and then adjusted the declaration carefully, but that is just SO 1970's (a decade I remember somewhat hazily and don't care to revisit :-). And, oh dear, I miscounted the number of characters in the string, so the fixed string would have been padded on the right to fill it out to the declared length and my comparison still wouldn't have worked.
The one case where I'll use CHAR instead of VARCHAR2 is if the variable of constant is only supposed to be a single character long. IMO declaring something as VARCHAR2(1) is just wrong. :-)
Just in passing I'll note that if you look in the package SYS.STANDARD you'll find that CHAR is declared as
subtype CHAR is VARCHAR2;
Thus, a CHAR is a VARCHAR2. Not sure how the space-padding is done, but it may well be that the space-padding is done at runtime and thus adds additional time.
Is there a performance advantage to one or the other? At most it won't be much. I suppose that if a CHAR variable has some space-padding it'll take a hair longer to compare than will an equivalent unpadded VARCHAR2 value, but in practical terms I don't believe this will matter. Also, since the space-padding is done at runtime that's going to add time. I suspect it's a wash, and will certainly be swamped by SQL effects.
Share and enjoy.

Answer 2

A CHAR datatype and VARCHAR2 datatype are stored identically ... So, in the case you describe, there's no difference.
The difference between a CHAR and a VARCHAR is that a CHAR(n) will ALWAYS be N bytes long, it will be blank padded upon insert to ensure this. A varchar2(n) on the other hand will be 1 to N bytes long, it will NOT be blank padded.

Answer 3

Hi this may be my assumption but varchar2 might have been used coz of performance,
a char is just a varchar2 blank padded out to the maximum length.
create table t ( x varchar2(30), y char(30) );
insert into t (x,y) values ( rpad('a',' ',30), 'a' );
IS ABSOLUTELY NOTHING, and given that the difference between columns X and Y below:
insert into t (x,y) values ('a','a')
is that X consumes 3 bytes (null indicator, leading byte length, 1 byte for 'a') and Y consumes 32 bytes (null indicator, leading byte length, 30 bytes for 'a ' )
Umm, varchar2 is going to be somewhat "at an advantage performance wise". It helps us NOT AT ALL that char(30) is always 30 bytes - to us, it is simply a varchar2 that is blank padded out to the maximum length.