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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Bug in concat operator for Char? -- More Info
Дата
Msg-id 23505.1090455080@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Bug in concat operator for Char? -- More Info  (Andreas Pflug <pgadmin@pse-consulting.de>)
Список 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 по дате отправления:

Предыдущее
От: Andreas Pflug
Дата:
Сообщение: Re: BUG #1199: pgAdmin problem
Следующее
От: Frank van Vugt
Дата:
Сообщение: adding a primary key column to a temporary table fails (v7.4.3)