Re: [GENERAL] 'a' == 'a '

From: "Wilkin, Kurt" <Kurt(dot)Wilkin(at)fnzc(dot)co(dot)nz>
To: "Dann Corbit" <DCorbit(at)connx(dot)com>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: <Richard_D_Levine(at)raytheon(dot)com>, <general(at)postgresql(dot)org>, <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [GENERAL] 'a' == 'a '
Date: 2005-10-21 11:03:23
Message-ID: 0398A76017ECA44E9FF4AB46FB885A2502B15FC1@mail1w.fnzsl.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Dann Corbit wrote:
>> -----Original Message-----
>> From: Tom Lane [mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us]
>> Sent: Thursday, October 20, 2005 2:54 PM
>> To: Dann Corbit
>> Cc: Richard_D_Levine(at)raytheon(dot)com; general(at)postgresql(dot)org; pgsql-
>> hackers(at)postgresql(dot)org Subject: Re: [GENERAL] [HACKERS] 'a' == 'a '
>>
>> "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

For SQL Server, you are seeing the behaviour of the len function,
none of the data has been trimmed.
Using the same tables:

select len('x' + (fixed_30) + 'x'),
len('x' + varch_30 + 'x'),
len('x' + nchar_30 + 'x'),
len('x' + nvarc_30 + 'x')
from test_char

Result set :

32 7 32 7

Cheers, Kurt.

--
This electronic message together with any attachments is confidential and
intended for the named recipient's use only. If you are not the intended
recipient (i) do not copy, disclose or use the contents in any way, (ii)
please let us know by return email immediately then destroy the message, and
any hard copies of the message, and any attachments. The sender of this
message is not responsible for any changes made to this message and/or any
attachments and/or connection linkages to the Internet referred to in this
message after it has been sent. Unless otherwise stated, any pricing
information given in this message and/or attachments is indicative only, is
subject to change and does not constitute an offer to buy or sell securities
or derivatives at any price quoted. Any reference to the terms of executed
transactions should be treated as preliminary only and subject to separate
formal written notification. Where reference is made to research material
and/or research recommendations, the basis of the provision of such research
material and/or recommendations is set out in the relevant disclaimer.

Browse pgsql-hackers by date

  From Date Subject
Next Message Martijn van Oosterhout 2005-10-21 11:53:32 Re: Question about Ctrl-C and less
Previous Message Magnus Hagander 2005-10-21 08:01:03 Re: 8.04 and RedHat/CentOS init script issue and sleep