Re: Rethinking plpgsql's assignment implementation

ne 3. 1. 2021 v 19:07 odesílatel Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> napsal:

> Pavel Stehule <pavel(dot)stehule(at)gmail(dot)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.)
>

I understand

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

Yes, the UPDATE should be changed. This is not a pretty important corner
case. But any inconsistency can be messy for users.

I don't see any interesting use case for current behavior, but it is a
corner case.

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

with pleasure

Regards

Pavel

> regards, tom lane
>