Thread

Commits

  1. Tidy up error reporting when converting PL/Python arrays.

  1. Error code missing for "wrong length of inner sequence" error

    Heikki Linnakangas <hlinnaka@iki.fi> — 2020-10-01T10:54:43Z

    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
    
    
    
    
  2. Re: Error code missing for "wrong length of inner sequence" error

    Daniel Gustafsson <daniel@yesql.se> — 2020-10-01T11:21:46Z

    > 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
    
    
    
  3. Re: Error code missing for "wrong length of inner sequence" error

    Heikki Linnakangas <hlinnaka@iki.fi> — 2020-10-02T11:44:54Z

    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
    
  4. Re: Error code missing for "wrong length of inner sequence" error

    Daniel Gustafsson <daniel@yesql.se> — 2020-10-02T12:06:48Z

    > 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
    
    
    
  5. Re: Error code missing for "wrong length of inner sequence" error

    Heikki Linnakangas <hlinnaka@iki.fi> — 2020-10-02T15:34:26Z

    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