Tatsuo Ishii <[EMAIL PROTECTED]> writes:
>>>> Can you give me any example for this case?
>>
>> UPDATE foo SET bpcharcol = 'a'::char || 'b'::char;
>>
>> UPDATE foo SET bpcharcol = upper('abc');
> In those cases above bpchar() will be called anyway, so I don't see
> MULTIBYTE length coerce problems there.
So it will, but *only* because the parser realizes that it needs to
add a call to bpchar(). If exprTypmod returns incorrect values then
it's possible that the parser would wrongly decide it didn't need to
call bpchar().
regards, tom lane
- Re: [HACKERS] length coerce for bpchar is broken since 7.0 Tom Lane
- Re: [HACKERS] length coerce for bpchar is broken since ... Tatsuo Ishii
- Re: [HACKERS] length coerce for bpchar is broken si... Tom Lane
- Re: [HACKERS] length coerce for bpchar is broke... Tatsuo Ishii
- Re: [HACKERS] length coerce for bpchar is b... Tom Lane
- Re: [HACKERS] length coerce for bpchar... Tatsuo Ishii
- Re: [HACKERS] length coerce for bp... Tom Lane
- Re: [HACKERS] length coerce for bp... Tatsuo Ishii
- Re: [HACKERS] length coerce for bp... Tom Lane
- Re: [HACKERS] length coerce for bp... Tatsuo Ishii
- Re: [HACKERS] length coerce for bp... Tom Lane
- Re: [HACKERS] length coerce for bpchar is broken since 7.0 Bruce Momjian
