Re: array_in sub function ReadArrayDimensions error message

From: jian he <jian(dot)universality(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
Subject: Re: array_in sub function ReadArrayDimensions error message
Date: 2024-07-10 04:25:56
Message-ID: CACJufxFS21wzDeHp4PBY6T9kRmCkUNkDznBqyFRpEOrkGbZReQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Jul 9, 2024 at 11:31 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> jian he <jian(dot)universality(at)gmail(dot)com> writes:
> > On Mon, Jul 8, 2024 at 10:42 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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"

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2024-07-10 04:42:33 Re: Internal error codes triggered by tests
Previous Message Michael Paquier 2024-07-10 04:16:15 Re: Injection points: preloading and runtime arguments