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
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 |