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

From Tom Lane
Subject Re: length coerce for bpchar is broken since 7.0
Date
Msg-id 29338.971756823@sss.pgh.pa.us
Whole thread Raw
In response to Re: length coerce for bpchar is broken since 7.0  (Tatsuo Ishii <t-ishii@sra.co.jp>)
Responses Re: length coerce for bpchar is broken since 7.0  (Tatsuo Ishii <t-ishii@sra.co.jp>)
List pgsql-hackers
Tatsuo Ishii <t-ishii@sra.co.jp> writes:
>>>> If VARSIZE returned from exprTypmod() and atttypmod passed to
>>>> coerce_type_typmod() is equal, the function node to call bpchar()
>>>> would not be added.
>> 
>> Um, what's wrong with that?  Seems to me that parse_coerce is doing
>> exactly what it's supposed to, ie, adding only length coercions
>> that are needed.

> 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.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tatsuo Ishii
Date:
Subject: Re: length coerce for bpchar is broken since 7.0
Next
From: Tatsuo Ishii
Date:
Subject: Re: length coerce for bpchar is broken since 7.0