I believe this has been fixed.
>Subject: [COMMITTERS] pgsql/src/backend/utils/adt (varchar.c)
>From: [EMAIL PROTECTED]
>To: [EMAIL PROTECTED]
>Date: Sun, 26 Nov 2000 06:35:23 -0500 (EST)
> Can someone comment on the status of this?
>
> > It seems the length coerce for bpchar is broken since 7.0
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Can someone comment on the status of this?
regression=# create table foo (f1 char(7));
CREATE
regression=# insert into foo values ('123456789');
INSERT 145180 1
regression=# select * from foo;
f1
-
1234567
(1 row)
Where's the problem?
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 e
Tatsuo Ishii <[EMAIL PROTECTED]> writes:
Can you give me any example for this case?
>>
>> UPDATE foo SET bpcharcol = 'a'::char || 'b'::char;
>>
>> UPDATE foo SET bpcharcol = upper('abc');
> In those cases above bpchar() will be called anyway, so I don't see
> MULTIBYTE length coerce proble
> Tatsuo Ishii <[EMAIL PROTECTED]> 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
Tatsuo Ishii <[EMAIL PROTECTED]> 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':
> Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> > I'm going to fix the problem by changing bpcharin() rather than
> > changing exprTypmod(). Surely we could fix the problem by changing
> > exprTypmod() for INSERT, however, we could not fix the similar problem
> > for COPY FROM in the same way. Chang
Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> I'm going to fix the problem by changing bpcharin() rather than
> changing exprTypmod(). Surely we could fix the problem by changing
> exprTypmod() for INSERT, however, we could not fix the similar problem
> for COPY FROM in the same way. Changing bpchar
> It's just hardwired knowledge about that particular datatype. In the
> light of your comments, it seems clear that the code here is wrong
> for the MULTIBYTE case: instead of plain VARSIZE(), it should be
> returning the number of multibyte characters + 4 (or whatever
> atttypmod is defined to
Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> Before going further, may I ask you a question. Why in exprTypmod() is
> bpchar() treated differently from other data types such as varchar?
It's just hardwired knowledge about that particular datatype. In the
light of your comments, it seems clear that
> > 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
Tatsuo Ishii <[EMAIL PROTECTED]> 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'
> > 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
Tatsuo Ishii <[EMAIL PROTECTED]> 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,
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 d
15 matches
Mail list logo
