Re: Bug in concat operator for Char? -- More Info

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andreas Pflug <pgadmin(at)pse-consulting(dot)de>
Cc: Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com>, josh(at)agliodbs(dot)com, pgsql-bugs(at)postgresql(dot)org, glenniii(at)mail(dot)utexas(dot)edu
Subject: Re: Bug in concat operator for Char? -- More Info
Date: 2004-07-22 00:11:20
Message-ID: 23505.1090455080@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Andreas Pflug <pgadmin(at)pse-consulting(dot)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

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Mason 2004-07-22 03:14:41 Strange AFTER UPDATE trigger behavior
Previous Message Andreas Pflug 2004-07-21 22:53:38 Re: BUG #1199: pgAdmin problem