Re: length coerce for bpchar is broken since 7.0

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: length coerce for bpchar is broken since 7.0
Дата
Msg-id 2910.971825787@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: length coerce for bpchar is broken since 7.0  (Tatsuo Ishii <t-ishii@sra.co.jp>)
Ответы Re: length coerce for bpchar is broken since 7.0
Список pgsql-hackers
Tatsuo Ishii <t-ishii@sra.co.jp> writes:
>> bpcharin() will most definitely NOT fix the problem, because it often
>> will not know the target column's typmod, if indeed there is an
>> identifiable target column at all. 

> Can you give me any example for this case?

UPDATE foo SET bpcharcol = 'a'::char || 'b'::char;

UPDATE foo SET bpcharcol = upper('abc');

In the first case bpcharin() will be invoked, but not in the context
of direct assignment to a table column, so it won't receive a valid
typmod.  In the second case bpcharin() will never be invoked at all,
because upper takes and returns text --- so 'abc' is not a bpchar
constant but a text constant.  You have to be sure that the parser
handles type length coercion correctly, and I think the cleanest way to
do that is to fix exprTypmod so that it knows how typmod is defined in
the MULTIBYTE case.
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tatsuo Ishii
Дата:
Сообщение: Re: length coerce for bpchar is broken since 7.0
Следующее
От: Mark Hollomon
Дата:
Сообщение: Re: DROP VIEW code question