Re: Damn bug! - Mailing list pgsql-bugs

From Tom Lane
Subject Re: Damn bug!
Date
Msg-id 2623.964159419@sss.pgh.pa.us
Whole thread Raw
In response to Re: Damn bug!  (JanWieck@t-online.de (Jan Wieck))
Responses Re: Damn bug!  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-bugs
JanWieck@t-online.de (Jan Wieck) writes:
>         pgsql=# update t1 set a[1] = 'new', a[2] = 'Empty';
>         UPDATE 1
>         pgsql=# select * from t1;
>                a
>         ---------------
>          {"new","bar"}
>         (1 row)

>     Don't know where this might happen, but it's interesting that
>     our ORDBMS treats some "text" literal special.

It's not dependent on what the text is, but it *is* dependent on
the length of the text.

regression=# select * from t1;
       a
---------------
 {"foo","bar"}
(1 row)

regression=# update t1 set a[1] = 'foo1', a[2] = 'barge';
UPDATE 1
regression=# select * from t1;
       a
----------------
 {"foo1","bar"}
(1 row)

regression=# update t1 set a[1] = 'foo2', a[2] = 'barg';
UPDATE 1
regression=# select * from t1;
        a
-----------------
 {"foo2","barg"}
(1 row)


I was confused a few days ago when people claimed that it was possible
to update different elements of an array with separate assignments in
a single UPDATE.  From what I know of the system, this *should not
work* --- you should get only one of the updates applied, because
each assignment will independently invoke array_set and construct
a separate new value for what's really the same field.

I think what we're seeing here is evidence that it really doesn't work.
Possibly there's some hack in array_set that overwrites the source
data (which it shouldn't be doing, in any case!) when the data length
doesn't need to change.  Needs more digging to understand in detail...

            regards, tom lane

pgsql-bugs by date:

Previous
From: JanWieck@t-online.de (Jan Wieck)
Date:
Subject: Re: Damn bug!
Next
From: Tom Lane
Date:
Subject: Re: Damn bug!