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