Re: BUG #18070: Assertion failed when processing error from plpy's iterator

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Alexander Lakhin <exclusion(at)gmail(dot)com>
Cc: pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #18070: Assertion failed when processing error from plpy's iterator
Date: 2023-09-16 08:27:28
Message-ID: ZQVm8KponTxqj8G3@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message PG Bug reporting form 2023-09-16 12:35:58 BUG #18114: FULL JOIN is replaced by LEFT JOIN in plan
Previous Message Alexander Lakhin 2023-09-16 06:00:00 Re: BUG #17928: Standby fails to decode WAL on termination of primary