Re: [HACKERS] length coerce for bpchar is broken since 7.0

[Tatsuo Ishii]

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