Re: length coerce for bpchar is broken since 7.0

> > Simply clipping multibyte strings by atttypmode might produce
> > incorrect multibyte strings. Consider a case inserting 3 multibyte
> > letters (each consisting of 2 bytes) into a char(5) column.
>
> It seems to me that this means that atttypmod or exprTypmod() isn't
> correctly defined for MULTIBYTE char(n) values. We should define
> typmod in such a way that they agree iff the string is correctly
> clipped. This might be easier said than done, perhaps, but I don't
> like the idea of having to apply length-coercion functions all the
> time because we can't figure out whether they're needed or not.

Before going further, may I ask you a question. Why in exprTypmod() is
bpchar() treated differently from other data types such as varchar?

switch (con->consttype)
{
case BPCHAROID:
if (!con->constisnull)
return VARSIZE(DatumGetPointer(con->constvalue));
break;
default:
break;
}

--
Tatsuo Ishii