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

From Bruce Momjian
Subject Re: length coerce for bpchar is broken since 7.0
Date
Msg-id 200101200241.VAA24305@candle.pha.pa.us
Whole thread Raw
In response to 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  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: length coerce for bpchar is broken since 7.0  (Tatsuo Ishii <t-ishii@sra.co.jp>)
List pgsql-hackers
Can someone comment on the status of this?

> It seems the length coerce for bpchar is broken since 7.0.
> In 6.5 when a string is inserted, bpchar() is called to properly clip
> the string. However in 7.0 (and probably current) bpchar() is not
> called anymore. 
> 
> coerce_type_typmod() calls exprTypmod(). exprTypmod() returns VARSIZE
> of the bpchar data only if the data type is bpchar (if the data type
> is varchar, exprTypmod just returns -1 and the parser add a function
> node to call varchar(). so there is no problem for varchar). If
> VARSIZE returned from exprTypmod() and atttypmod passed to
> coerce_type_typmod() is equal, the function node to call bpchar()
> would not be added.
> 
> I'm not sure if this was an intended efect of the change. Anyway we
> have to do the length coerce for bpchar somewhere and I'm thinking now
> is doing in bpcharin(). This would also solve the problem in copy in a
> mail I have posted.
> 
> Comments?
> --
> Tatsuo Ishii
> 


--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 


pgsql-hackers by date:

Previous
From: mlw
Date:
Subject: Re: 7.0.3 reproduceable serious select error
Next
From: Bruce Momjian
Date:
Subject: Rules and SELECT