On Tuesday, July 9, 2024, jian he <
jian.universality@gmail.com> wrote:
I also found other issues, like.
select '[-2:2147483644]={3}'::int[];
ERROR: malformed array literal: "[-2:2147483644]={3}"
LINE 1: select '[-2:2147483644]={3}'::int[];
^
DETAIL: Specified array dimensions do not match array contents.
select '[-2:2147483645]={3}'::int[];
ERROR: array size exceeds the maximum allowed (134217727)
LINE 1: select '[-2:2147483645]={3}'::int[];
^
Both cases exceed the maximum allowed (134217727), but error is different.
also
They do not both exceed (i.e., strictly greater than) 134217727 - the first case equals it which is why it gets past the dimension specification parser.
"ERROR: array size exceeds the maximum allowed (134217727)"
is weird. we are still validating the dimension info function, we
don't even know the actual size of the array.
maybe
"ERROR: array dimensions specified array size exceeds the maximum
allowed (134217727)"
How about:
“array dimension %d declared size exceeds the maximum allowed %d”, ndim, (int) MaxArraySize
But while that message fits the code aren’t we supposed to be checking, after processing all dimensions, whether the combined number of cells is greater than MaxArraySize? Obviously if any one dimension is the whole thing will be, so this specific check and error is still useful.
to address David G. Johnston concern,
in ReadArrayDimensions, some error message can unconditionally mention
errhint like:
errhint("array dimension template is \"[lower_bound:upper_bound]\", we
can optional have 6 of this"
I suppose, but if they are writing json array syntax that hint is going to mean little to them. Pointing out that their use of [] brackets is wrong and that {} should be used seems more helpful. The extent we need to consider people writing literal dimensions to set their lower bound to something other than one seems close to none and not needing a hint, IMO.
That said, it isn’t making it back to us if our users are actually having this confusion and would benefit meaningfully from such a hint.
David J.
