Here's what happens in SQL*Plus (both 9i and 7.3) ...
As you can see, SQL*Plus preserves trailing spaces SQL*Plus: Release 9.0.1.0.0 - Production on Fri Mar 1 08:45:40 2002 (c) Copyright 2001 Oracle Corporation. All rights reserved. Connected to: Oracle9i Enterprise Edition Release 9.0.1.0.0 - Production With the Partitioning option JServer Release 9.0.1.0.0 - Production SQL> desc sb_test Name Null? Type ----------------------------------------- -------- ---------------------------- PK_ID NOT NULL NUMBER NAME VARCHAR2(80) DOB DATE SQL> insert into sb_test values (1, 'aa ', sysdate); 1 row created. SQL> select '>' || name || '<' from sb_test; '>'||NAME||'<' -------------------------------------------------------------------------------- >aa < SQL*Plus: Release 3.3.3.0.0 - Production on Fri Mar 1 08:43:20 2002 Copyright (c) Oracle Corporation 1979, 1996. All rights reserved. Connected to: Oracle7 Server Release 7.3.3.5.0 - Production Release With the distributed option PL/SQL Release 2.3.3.5.0 - Production SQL> desc sb_test Name Null? Type ------------------------------- -------- ---- PK_ID NOT NULL NUMBER(10) NAME VARCHAR2(80) DOB DATE SQL> insert into sb_test values (1, 'aa ', sysdate); 1 row created. SQL> select '>' || name || '<' from sb_test; '>'||NAME||'<' -------------------------------------------------------------------------------- >aa < Michael Peppler wrote: >Jeff Hunter writes: > > I agree, it should be fixed. > > > > Peter J. Holzer wrote: > > > > >I don't think the current behaviour[1] is correct. In perl, strings can > > >have trailing spaces: "test" and "test " compare as not equal. > > >In Oracle varchar2 can store strailing spaces: If I store 'test ' in a > > >varchar2 column, I get back 'test ' and not 'test' or 'test '. > >Are you *sure* that you get 'test ' back??? > >I'm not be an Oracle specialist, but I know that trailing spaces in >varchar() columns are normally removed on insert. This is definitely >the case for Sybase - irrespective of the client that is used to >access the data. I also seem to recall that this behaviour is a SQL >standard. > >Michael >
