Error code missing for "wrong length of inner sequence" error
In PLySequence_ToArray_recurse(), there's this check:
if (PySequence_Length(list) != dims[dim])
ereport(ERROR,
(errmsg("wrong length of inner sequence: has length %d, but %d was expected",
(int) PySequence_Length(list), dims[dim]),
(errdetail("To construct a multidimensional array, the inner sequences must all have the same length."))));
It's missing an error code, making it implicitly ERRCODE_INTERNAL_ERROR,
which is surely not right. That's simple to fix, but what error code
should we use?
I'm inclined to use ERRCODE_ARRAY_SUBSCRIPT_ERROR, because that's used
in the similar error message with SQL ARRAY expression, like "ARRAY[[1],
[2, 3]]". Most checks when converting between SQL and Python types use
the PLy_elog() function, which uses the genericc
ERRCODE_EXTERNAL_ROUTINE_EXCEPTION error code, but I think
ERRCODE_ARRAY_SUBSCRIPT_ERROR is better.
You get this error e.g. if you try to return a python lists of lists
from a PL/python function as a multi-dimensional array, but the sublists
have different lengths:
create function return_array() returns int[] as $$
return [[1], [1,2]]
$$ language plpythonu;
postgres=# select return_array();
ERROR: wrong length of inner sequence: has length 2, but 1 was expected
DETAIL: To construct a multidimensional array, the inner sequences must
all have the same length.
CONTEXT: while creating return value
PL/Python function "return_array"
Thoughts? If not, I'm going to add
errcode(ERRCODE_ARRAY_SUBSCRIPT_ERROR) to that.
- Heikki
On 1 Oct 2020, at 12:54, Heikki Linnakangas <hlinnaka@iki.fi> wrote:
Most checks when converting between SQL and Python types use the PLy_elog() function, which uses the genericc ERRCODE_EXTERNAL_ROUTINE_EXCEPTION error code, but I think ERRCODE_ARRAY_SUBSCRIPT_ERROR is better.
On that note, wouldn't the dimension check errors in PLySequence_ToArray be
just as well off using normal ereport()'s? Only one of them seem to error out
in a way that could propagate an error from Python to postgres.
Thoughts? If not, I'm going to add errcode(ERRCODE_ARRAY_SUBSCRIPT_ERROR) to that.
+1 on using ERRCODE_ARRAY_SUBSCRIPT_ERROR as it better conveys meaning.
cheers ./daniel
On 01/10/2020 14:21, Daniel Gustafsson wrote:
On 1 Oct 2020, at 12:54, Heikki Linnakangas <hlinnaka@iki.fi> wrote:
Most checks when converting between SQL and Python types use the PLy_elog() function, which uses the genericc ERRCODE_EXTERNAL_ROUTINE_EXCEPTION error code, but I think ERRCODE_ARRAY_SUBSCRIPT_ERROR is better.
On that note, wouldn't the dimension check errors in PLySequence_ToArray be
just as well off using normal ereport()'s? Only one of them seem to error out
in a way that could propagate an error from Python to postgres.
Yes, you are right. I was going to say that we are not very consistent
on when to use ereport() and when PLy_elog() in general, but looking
closer, we are. Outside the array-conversion functions, PLy_elog() is
only used when a Python C API call fails, and ereport() is used otherwise.
Patch attached.
- Heikki
Attachments:
0001-Tidy-up-error-reporting-when-converting-PL-Python-ar.patchtext/x-patch; charset=UTF-8; name=0001-Tidy-up-error-reporting-when-converting-PL-Python-ar.patchDownload+15-6
On 2 Oct 2020, at 13:44, Heikki Linnakangas <hlinnaka@iki.fi> wrote:
On 01/10/2020 14:21, Daniel Gustafsson wrote:
On 1 Oct 2020, at 12:54, Heikki Linnakangas <hlinnaka@iki.fi> wrote:
Most checks when converting between SQL and Python types use the PLy_elog() function, which uses the genericc ERRCODE_EXTERNAL_ROUTINE_EXCEPTION error code, but I think ERRCODE_ARRAY_SUBSCRIPT_ERROR is better.On that note, wouldn't the dimension check errors in PLySequence_ToArray be
just as well off using normal ereport()'s? Only one of them seem to error out
in a way that could propagate an error from Python to postgres.Yes, you are right. I was going to say that we are not very consistent on when to use ereport() and when PLy_elog() in general, but looking closer, we are. Outside the array-conversion functions, PLy_elog() is only used when a Python C API call fails, and ereport() is used otherwise.
I did another scan as well and couldn't find any other offenders.
Patch attached.
LGTM.
cheers ./daniel
On 02/10/2020 15:06, Daniel Gustafsson wrote:
On 2 Oct 2020, at 13:44, Heikki Linnakangas <hlinnaka@iki.fi> wrote:
On 01/10/2020 14:21, Daniel Gustafsson wrote:
On that note, wouldn't the dimension check errors in PLySequence_ToArray be
just as well off using normal ereport()'s? Only one of them seem to error out
in a way that could propagate an error from Python to postgres.Yes, you are right. I was going to say that we are not very
consistent on when to use ereport() and when PLy_elog() in general,
but looking closer, we are. Outside the array-conversion functions,
PLy_elog() is only used when a Python C API call fails, and
ereport() is used otherwise.I did another scan as well and couldn't find any other offenders.
Pushed. Thanks for checking!
- Heikki