Re: Rethinking plpgsql's assignment implementation - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: Rethinking plpgsql's assignment implementation
Date
Msg-id CAFj8pRAP6XVfEDeN0XfnBgWFV3Frcok08Mts6zF__u5UsGgz8w@mail.gmail.com
Whole thread Raw
In response to Re: Rethinking plpgsql's assignment implementation  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Rethinking plpgsql's assignment implementation
List pgsql-hackers


ne 3. 1. 2021 v 19:07 odesílatel Tom Lane <tgl@sss.pgh.pa.us> napsal:
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.)

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

pgsql-hackers by date:

Previous
From: Amine Tengilimoglu
Date:
Subject: pg_rewind restore_command issue in PG12
Next
From: David Fetter
Date:
Subject: Re: Implement for window functions