Re: BUG #18070: Assertion failed when processing error from plpy's iterator - Mailing list pgsql-bugs

From Michael Paquier
Subject Re: BUG #18070: Assertion failed when processing error from plpy's iterator
Date
Msg-id ZQVm8KponTxqj8G3@paquier.xyz
Whole thread Raw
In response to Re: BUG #18070: Assertion failed when processing error from plpy's iterator  (Alexander Lakhin <exclusion@gmail.com>)
Responses Re: BUG #18070: Assertion failed when processing error from plpy's iterator
List pgsql-bugs
On Fri, Sep 15, 2023 at 08:00:00PM +0300, Alexander Lakhin wrote:
> -        /* Since we have a format string, we cannot have a SPI detail. */
> -        Assert(detail == NULL);
> -
> -        /* If there's an exception message, it goes in the detail. */
> -        if (xmsg)
> +        /*
> +         * When we have no detail from the error data, an exception message,
> +         * if not empty, goes in the detail.
> +         */
> +        if (detail == NULL && xmsg != NULL)
>              detail = xmsg;

Yeah, I think that you're right here to enforce the use of a DETAIL
message if it exists instead of the xmsg.  At least that feels more
natural because we would get the same error when attempting to select
from a composite type.

How about adding a regression test?  Say in plpython_error.sql where
we already check a bunch of error patterns?
--
Michael

Attachment

pgsql-bugs by date:

Previous
From: Alexander Lakhin
Date:
Subject: Re: BUG #17928: Standby fails to decode WAL on termination of primary
Next
From: PG Bug reporting form
Date:
Subject: BUG #18114: FULL JOIN is replaced by LEFT JOIN in plan