Re: Cleaning up array_in()

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
Cc: jian he <jian(dot)universality(at)gmail(dot)com>, Alexander Lakhin <exclusion(at)gmail(dot)com>, Nikhil Benesch <nikhil(dot)benesch(at)gmail(dot)com>, Nathan Bossart <nathandbossart(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Cleaning up array_in()
Date: 2023-11-13 18:23:30
Message-ID: 2162169.1699899810@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I wrote:
> Heikki Linnakangas <hlinnaka(at)iki(dot)fi> writes:
>> 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.

I pushed the main patch. Here's a proposed delta to deal with
the bogus-dimensionality-count issue. There are a few more places
where I left things alone because the code does know what the
intended dimensionality will be; so there are still two versions
of the translatable error message.

regards, tom lane

Attachment Content-Type Size
v1-dont-report-inaccurate-dimension-count.patch text/x-diff 2.5 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Nathan Bossart 2023-11-13 18:59:50 retire MemoryContextResetAndDeleteChildren backwards compatibility macro
Previous Message Tom Lane 2023-11-13 18:17:32 Re: COPY TO (FREEZE)?