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

> -----Original Message-----
> From: pgsql-hackers-owner@postgresql.org [mailto:pgsql-hackers-
> owner@postgresql.org] On Behalf Of Greg Stark
> Sent: Wednesday, October 19, 2005 11:17 PM
> To: Tom Lane
> Cc: Chris Travers; josh@agliodbs.com; pgsql-hackers@postgresql.org;
Dann
> Corbit; Stephan Szabo; Terry Fielder; Tino Wildenhain; Marc G.
Fournier;
> Richard_D_Levine@raytheon.com; pgsql-general@postgresql.org
> Subject: Re: [GENERAL] [HACKERS] 'a' == 'a '
>
> Tom Lane <tgl@sss.pgh.pa.us> writes:
>
> > Chris Travers <chris@travelamericas.com> writes:
> > > If I understand the spec correctly, it seems to indicate that this
is
> > > specific to the locale/character set.
> >
> > The spec associates padding behavior with collations, which per spec
are
> > separate from the datatypes --- that is, you should be able to able
to
> > specify a collation for each string-type table column (whether
char(N)
> > or varchar(N)) and even for each literal string constant.  We do not
> > currently have that capability, and accordingly fall back to binding
> > PAD SPACE behavior to char(N) and NO PAD behavior to varchar(N).
> >
> > AFAICS this choice is allowed by the spec since the default
collation is
> > implementation-defined.
>
> Does it even make sense for char(N) to not be space padded? I had the
> impression char(N) was always N characters long, not more or less. I
can't
> picture any other character being used for padding, then you would
need a
> more
> flexible rtrim function.
>
> And I can understand the collation order determining whether 'a' and
'a '
> compare equal. But surely if you store 'a' in a varchar(N) you have to
get
> 'a'
> back out, not some other string! Does the spec really allow varchar to
> actually be padded and not just compare ignoring trailing space?
>
>
> (I can't believe anyone really wants varchar to be space padded. Space
> padding
> always seemed like a legacy feature for databases with fixed record
length
> data types. Why would anyone want a string data type that can't
represent
> all
> strings?)

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.

It is only the action to be taken when a comparison operation is
performed.