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