From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Chapman Flack <chap(at)anastigmatix(dot)net>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Rethinking plpgsql's assignment implementation |
Date: | 2021-01-03 15:25:33 |
Message-ID: | CAFj8pRCKqxmKVEfP8UoEGCpHJJDdLDXVRG=bXb6G9Fsc7NKY6w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Isaac Morland | 2021-01-03 16:32:30 | Re: Safety/validity of resetting permissions by updating system tables |
Previous Message | Tomas Vondra | 2021-01-03 14:35:39 | Re: Handing off SLRU fsyncs to the checkpointer |