Re: Cleaning up array_in()

Heikki Linnakangas <hlinnaka(at)iki(dot)fi> writes:
> On 09/11/2023 18:57, Tom Lane wrote:
>> Barring objections, I think v12 is committable.

> Looks good to me. Just two little things caught my eye:

> 1.
> The function comments in ReadArrayDimensions and ReadArrayStr don't make
> it clear that these arrays need to be initialized like this.
> ReadArrayDimensions() says that they are output variables, and
> ReadArrayStr() doesn't mention anything about having to initialize them.

Roger, will fix that.

> 2. This was the same before this patch, but:

> postgres=# select '{{{{{{{{{{1}}}}}}}}}}'::int[];
> ERROR: number of array dimensions (7) exceeds the maximum allowed (6)
> LINE 1: select '{{{{{{{{{{1}}}}}}}}}}'::int[];
> ^
> The error message isn't great, as the literal contains 10 dimensions,
> not 7 as the error message claims.

Yeah. To make that report accurate, we'd have to somehow postpone
issuing the error until we've seen all the left braces (or at least
all the initial ones). There's a related problem in reading an
explicitly-dimensioned array:

postgres=# select '[1][2][3][4][5][6][7][8][9]={}'::text[];
ERROR: number of array dimensions (7) exceeds the maximum allowed (6)

I kind of think it's not worth the trouble. What was discussed
upthread was revising the message to not claim it knows how many
dimensions there are. The related cases in plperl and plpython just
say "number of array dimensions exceeds the maximum allowed (6)",
and there's a case to be made for adjusting the core messages
similarly. I figured that could be a separate patch though,
since it'd touch more than array_in (there's about a dozen
occurrences of the former wording).

regards, tom lane