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
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 |