| From: | "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> | 
|---|---|
| To: | <DCorbit(at)connx(dot)com>, <tgl(at)sss(dot)pgh(dot)pa(dot)us> | 
| Cc: | <general(at)postgresql(dot)org>, <pgsql-hackers(at)postgresql(dot)org>, <Richard_D_Levine(at)raytheon(dot)com> | 
| Subject: | Re: [GENERAL] 'a' == 'a ' | 
| Date: | 2005-10-21 13:40:26 | 
| Message-ID: | 4358A97F0200002500000183@gwmta.wicourts.gov | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-hackers | 
I wonder how widespread the MicroSoft behavior is  Sybase ASE,
for example, gives this result set:
30 5 30 5
That seems more appropriate to me.
-Kevin
> "Dann Corbit" <DCorbit(at)connx(dot)com> writes:
> > I guess that additional ambiguity arises if you add additional
spaces to
> > the end.  Many database systems solve this by trimming the
characters
> > from the end of the string upon storage and the returned string will
not
> > have any trailing blanks.
> 
> Can you document that?  ISTM that that would effectively make char(n)
> and varchar(n) exactly equivalent, which is ... um ... a bit stupid.
This is SQL*Server:
drop table test_char
go
create table test_char(
  fixed_30 char(30),
  varch_30 varchar(30),
  nchar_30  nchar(30),
  nvarc_30 nvarchar(30)
)
go
insert into test_char values('Dann ', 'Dann ', 'Dann ', 'Dann ')
go
select len(fixed_30), len(varch_30), len(nchar_30), len(nvarc_30) 
from test_char
go
Result set:
4	4	4	4
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Martijn van Oosterhout | 2005-10-21 13:40:43 | Re: Question about Ctrl-C and less | 
| Previous Message | mark | 2005-10-21 12:48:31 | Re: Question about Ctrl-C and less |