Re: length coerce for bpchar is broken since 7.0

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: length coerce for bpchar is broken since 7.0
Date: 2000-10-17 23:36:27
Message-ID: 2910.971825787@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp> writes:
>> bpcharin() will most definitely NOT fix the problem, because it often
>> will not know the target column's typmod, if indeed there is an
>> identifiable target column at all.

> Can you give me any example for this case?

UPDATE foo SET bpcharcol = 'a'::char || 'b'::char;

UPDATE foo SET bpcharcol = upper('abc');

In the first case bpcharin() will be invoked, but not in the context
of direct assignment to a table column, so it won't receive a valid
typmod. In the second case bpcharin() will never be invoked at all,
because upper takes and returns text --- so 'abc' is not a bpchar
constant but a text constant. You have to be sure that the parser
handles type length coercion correctly, and I think the cleanest way to
do that is to fix exprTypmod so that it knows how typmod is defined in
the MULTIBYTE case.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Mark Hollomon 2000-10-18 01:02:25 Re: DROP VIEW code question
Previous Message Tatsuo Ishii 2000-10-17 22:57:26 Re: length coerce for bpchar is broken since 7.0