On Fri, Jul 19, 2024 at 07:32:18PM -0400, Joseph Koshakow wrote:
> On Fri, Jul 19, 2024 at 2:45 PM Nathan Bossart <nathandbossart@gmail.com>
> wrote:
>> + /* dim[i] = 1 + upperIndx[i] - lowerIndx[i]; */
>> + if (pg_add_s32_overflow(1, upperIndx[i], &dim[i]))
>> + ereport(ERROR,
>> + (errcode(ERRCODE_PROGRAM_LIMIT_EXCEEDED),
>> + errmsg("array upper bound is too large: %d",
>> + upperIndx[i])));
>> + if (pg_sub_s32_overflow(dim[i], lowerIndx[i], &dim[i]))
>> + ereport(ERROR,
>> + (errcode(ERRCODE_PROGRAM_LIMIT_EXCEEDED),
>> + errmsg("array size exceeds the maximum allowed
> (%d)",
>> + (int) MaxArraySize)));
>>
>> I think the problem with fixing it this way is that it prohibits more than
>> is necessary.
>
> My understanding is that 2147483647 (INT32_MAX) is not a valid upper
> bound, which is what the first overflow check is checking. Any query of
> the form
> `INSERT INTO arroverflowtest(i[<lb>:2147483647]) VALUES ('{...}');`
> will fail with an error of
> `ERROR: array lower bound is too large: <lb>`
>
> The reason is the following bounds check found in arrayutils.c
>
> /*
> * Verify sanity of proposed lower-bound values for an array
> *
> * The lower-bound values must not be so large as to cause overflow when
> * calculating subscripts, e.g. lower bound 2147483640 with length 10
> * must be disallowed. We actually insist that dims[i] + lb[i] be
> * computable without overflow, meaning that an array with last
> subscript
> * equal to INT_MAX will be disallowed.
I see. I'm still not sure that this is the right place to enforce this
check, especially given we explicitly check the bounds later on in
construct_md_array(). Am I understanding correctly that the main
behavioral difference between these two approaches is that users will see
different error messages?
--
nathan
