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

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

I continue in review.

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"

More, this behave is not documented

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

Regards

Pavel





pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: Handing off SLRU fsyncs to the checkpointer
Next
From: Isaac Morland
Date:
Subject: Re: Safety/validity of resetting permissions by updating system tables