Re: length coerce for bpchar is broken since 7.0 - Mailing list pgsql-hackers

From Tatsuo Ishii
Subject Re: length coerce for bpchar is broken since 7.0
Date
Msg-id 20001017133825T.t-ishii@sra.co.jp
Whole thread Raw
In response to Re: length coerce for bpchar is broken since 7.0  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: length coerce for bpchar is broken since 7.0  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
> > 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


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: length coerce for bpchar is broken since 7.0
Next
From: Tom Lane
Date:
Subject: Re: length coerce for bpchar is broken since 7.0