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 по дате отправления: