| 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: | Whole Thread | Raw Message | 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 |
| 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)? |