Unexpected result in RPAD - sql

Question

I am using Oracle 11g. I am using the Scott account and the demo EMP table. I inserted one record with ENAME BRUCE WILLIAM. My aim is to show the first name and last name in two columns. I used this code:
select trim rpad(ename, instr(ename,' '))) "First Name",
trim(substr(ename, instr(ename,' '))) "Last Name"
from emp;
This gives a weird result. The First Name is extended to second line. I used
select trim(substr(ename, 1, instr(ename,' '))),
trim(substr(ename, instr(ename, ' ')))
from emp;
I got the expected output. My question is why the first line of query is giving extra spaces?

Answer 1

You are not getting extra spaces in your string, and if you were then the trim() would remove them again. SQL*Plus is just formatting the results in a way you don't expect. The documentation mentions the default formatting for column types, and can usually work it out for system functions (though the characterset can make it bigger than you expect).
It seems like SQL*Plus, and SQL Developer, can't determine a sensible default for your rpad case, but can for your substr. Well, SQL*Plus is really just getting a result set cursor from the database, and using the cursor metadata to determine the default widths to apply to the fields for display, so it isn't getting the length you expect from that metadata. But what length should it use?
The database only knows how big the rpad value can be if the padding length is a simple value - it doesn't even mind zero (it returns null, which you're relying on). If the padding length is determined by a function then there's no way to tell how big the result could be, apart from calculating it for every value in the result set before returning the metadata and and actual data, which isn't practical, and would produce inconsistent output as the data changed.
It also wouldn't be practical to try to determine a theoretical maximum, even though it looks superficially straightforward in your case. substr can't ever return something longer than the original value; but rpad could potentially produce something huge even from a short input value, so it has to allow for that possibility if it can't easily determine a limit (i.e. from a fixed value).
So it plays safe and allows for it being up to the maximum length for a varchar2, which is 4000 characters, as this dynamic SQL demonstrates:
declare
l_curid integer;
l_desctab dbms_sql.desc_tab3;
l_colcnt integer;
begin
l_curid := dbms_sql.open_cursor;
dbms_sql.parse(l_curid, 'select rpad(ename, instr(ename,'' '')), '
|| 'rpad(ename, 4), '
|| 'substr(ename, 1, instr(ename,'' '')) '
|| 'from emp where ename like ''B%''' , dbms_sql.native);
dbms_sql.describe_columns3(l_curid, l_colcnt, l_desctab);
for i in 1 .. l_colcnt loop
dbms_output.put_line('column ' || i
|| ' ' || l_desctab(i).col_name
|| ' type ' || l_desctab(i).col_type
|| ' length ' || l_desctab(i).col_max_len
);
end loop;
dbms_sql.close_cursor(l_curid);
end;
/
column 1 RPAD(ENAME,INSTR(ENAME,'')) type 1 length 4000
column 2 RPAD(ENAME,4) type 1 length 16
column 3 SUBSTR(ENAME,1,INSTR(ENAME,'')) type 1 length 40
As you can see, it knows the length for a fixed-length rpad and a substr (note the size is four times the actual string length due to the multibyte characterset), but falls back to the maximum for the rpad using a function.
What you're seeing is SQL*Plus showing a 4000-char column. If you did this in SQL Developer you would see the header for that column is indeed 4000 characters. SQL*Plus helps a bit by reducing the displayed column header to the line size, and wraps the next column onto a separate line.

Answer 2

lpad ('string', n [, 'string_pad')
rpad ('string', n [, 'string_pad')
string is left padded to length n with string_pad. If string_pad is ommited, a space will be used as default
rpad is similar, but pads right instead of left.
from http://www.adp-gmbh.ch/ora/sql/rpad.html
and here is good example for understanding
begin
for i in 1 .. 15 loop
dbms_output.put_line(
rpad('string', i) || '<'
);
end loop;
end;