Re: Rethinking plpgsql's assignment implementation

Pavel Stehule <pavel.stehule@gmail.com> writes:
> I found inconsistency in work with slicings (this is not directly related
> to this patch, but can be interesting, because with new functionality the
> array slicings can be edited more often).

> a = array[1,2,3,4,5];
> a[1:5] = 10; -- correctly fails, although for some people can be more
> natural semantic setting a[1..5] to value 10
> a[1:5] = NULL;  does nothing - no fail, no value change ??? Is it correct
> a[1:5] = ARRAY[1]; -- correctly fails ERROR:  source array too small
> but
> a[1:5] = ARRAY[1,2,3,4,5,6]; -- this statement works, but 6 is ignored. Is
> it correct? I expected "source array too big"

Hm.  All of these behaviors have existed for a long time in the context
of UPDATE statements:

regression=# create table t1 (a int[]);
CREATE TABLE
regression=# insert into t1 values(array[1,2,3,4,5]);
INSERT 0 1
regression=# table t1;
      a
-------------
 {1,2,3,4,5}
(1 row)

regression=# update t1 set a[1:5] = 10;
ERROR:  subscripted assignment to "a" requires type integer[] but expression is of type integer
regression=# update t1 set a[1:5] = null;
UPDATE 1
regression=# table t1;
      a
-------------
 {1,2,3,4,5}
(1 row)

(Note that in this example, the null is implicitly typed as int[];
so it's not like the prior example.)

regression=# update t1 set a[1:5] = array[1];
ERROR:  source array too small
regression=# update t1 set a[1:5] = array[1,2,3,4,6,5];
UPDATE 1
regression=# table t1;
      a
-------------
 {1,2,3,4,6}
(1 row)

I agree this is inconsistent, but given the way this patch works,
we'd have to change UPDATE's behavior if we want plpgsql to do
something different.  Not sure if we can get away with that.

> anything other looks well, all tests passed, and in my benchmarks I don't
> see any slowdowns , so I'll mark this patch as ready for committer

Thanks!

            regards, tom lane