Re: Bug in concat operator for Char? -- More Info - Mailing list pgsql-bugs

From Tom Lane
Subject Re: Bug in concat operator for Char? -- More Info
Date
Msg-id 23505.1090455080@sss.pgh.pa.us
Whole thread Raw
In response to Re: Bug in concat operator for Char? -- More Info  (Andreas Pflug <pgadmin@pse-consulting.de>)
List pgsql-bugs
Andreas Pflug <pgadmin@pse-consulting.de> writes:
> Tom Lane wrote:
>> Food for thought: in 7.4,
>>
>> regression=# select ('X   '::char) = ('X'::char);
>> ?column?
>> ----------
>> t
>> (1 row)
>>
>> regression=# select ('Y   '::char) = ('Y'::char);
>> ?column?
>> ----------
>> t
>> (1 row)
>>
>> regression=# select ('X   '::char || 'Y   '::char) = ('X'::char || 'Y'::char);
>> ?column?
>> ----------
>> t
>> (1 row)
>>
>> If we change || as is proposed in this thread, then the last case would
>> yield 'false', because the first concatenation would yield 'X  Y  '
>> which is not equal to 'XY' no matter what you think about trailing
>> spaces.  I find it a bit disturbing that the concatenation of equal
>> values would yield unequal values.

> Well this indicates that the first two examples are questionable.

Indeed, but AFAICS this behavior is mandated by the SQL standard.
(Note we are interpreting char(N) as always having the PAD SPACE
behavior, though the spec really wants us to associate that with
a collation instead.)

            regards, tom lane

pgsql-bugs by date:

Previous
From: Andreas Pflug
Date:
Subject: Re: BUG #1199: pgAdmin problem
Next
From: Frank van Vugt
Date:
Subject: adding a primary key column to a temporary table fails (v7.4.3)