Re: [HACKERS] 'a' == 'a '

From: "John D(dot) Burger" <john(at)mitre(dot)org>
To: "Dann Corbit" <DCorbit(at)connx(dot)com>
Cc: "<pgsql-hackers(at)postgresql(dot)org>" <pgsql-hackers(at)postgresql(dot)org>, pgsql-general General <pgsql-general(at)postgresql(dot)org>
Subject: Re: [HACKERS] 'a' == 'a '
Date: 2005-10-20 19:53:24
Message-ID: db02dc00603e81f57542221ab7d3c424@mitre.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

[Removed all the non-list addresses]

Dann Corbit wrote:

> Let me make something clear:
> When we are talking about padding here it is only in the context of a
> comparison operator and NOT having anything to do with storage.
>
> Given two strings of different in a comparison, most database systems
> (by default) will blank pad the shorter string so that they are the
> same
> length before performing the comparison.
>
> Hence, you will see that 'Danniel' = 'Danniel ' is true in most cases.
>
> Now, this really does not have any connection with storage or varchar
> or
> bpchar or char or text or anything like that.

Is this really true??? My understanding of the spec was that this was
=exactly= the difference between char(N) and varchar(N) - the former is
padded to length N when you store it, or at least the DB has to act as
if this is the case. Can someone quote the appropriate chapter and
verse?

Thanks.

- John D. Burger
MITRE

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Dann Corbit 2005-10-20 19:56:16 Re: [HACKERS] 'a' == 'a '
Previous Message Steve V 2005-10-20 19:44:07 Precompiled win32 binary for getCurrentTransactionID?

Browse pgsql-hackers by date

  From Date Subject
Next Message Dann Corbit 2005-10-20 19:56:16 Re: [HACKERS] 'a' == 'a '
Previous Message Tom Lane 2005-10-20 19:47:16 Re: 8.04 and RedHat/CentOS init script issue and sleep