Re: length coerce for bpchar is broken since 7.0

> 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.

In those cases above bpchar() will be called anyway, so I don't see
MULTIBYTE length coerce problems there.
--
Tatsuo Ishii