Re: array_in sub function ReadArrayDimensions error message - Mailing list pgsql-hackers

From jian he
Subject Re: array_in sub function ReadArrayDimensions error message
Date
Msg-id CACJufxFS21wzDeHp4PBY6T9kRmCkUNkDznBqyFRpEOrkGbZReQ@mail.gmail.com
Whole thread Raw
In response to Re: array_in sub function ReadArrayDimensions error message  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: array_in sub function ReadArrayDimensions error message
List pgsql-hackers
On Tue, Jul 9, 2024 at 11:31 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> jian he <jian.universality@gmail.com> writes:
> > On Mon, Jul 8, 2024 at 10:42 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >> One possibility could be
> >> ...
> >> that is, only say "Missing "]"" if there's no ']' anywhere, and
> >> otherwise just say the dimensions are wrong.  This could be fooled
> >> by a ']' that's part of some string in the data, but even then the
> >> errdetail isn't wrong.
> >>
> >> Or we could just say "Array dimensions have invalid syntax."
> >> unconditionally.
>
> > please check attached.
>
> Meh.  This just replaces one possibly-off-point error message
> with a different one that will be off-point in a different set
> of cases.  I think we should simply reduce the specificity of
> the message.

After playing around, I agree with you that reducing the specificity of
the message here is better.


> BTW, I think we have pretty much the same issue with respect
> to the check for "=" later on.  For instance, if someone
> is confused about whether to insert commas:
>
> =# select '[1:1],[1:2]={{3,4}}'::int[];
> ERROR:  malformed array literal: "[1:1],[1:2]={{3,4}}"
> LINE 1: select  '[1:1],[1:2]={{3,4}}'::int[];
>                 ^
> DETAIL:  Missing "=" after array dimensions.
>
> Here again, the problem is not a missing "=", it's invalid
> syntax somewhere before that.
>
> Another thing we could consider doing here (and similarly
> for your original case) is
>
> DETAIL:  Expected "=" not "," after array dimensions.
>
> The advantage of this is that it provides a little more
> clarity as to exactly where things went wrong.
>
this looks good to me.


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
"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)"


This customized dimension info is kind of obscure, even the
documentation of it is buried
in the third paragraph of
https://www.postgresql.org/docs/current/arrays.html#ARRAYS-IO


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"



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Injection points: preloading and runtime arguments
Next
From: Michael Paquier
Date:
Subject: Re: Internal error codes triggered by tests