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

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: BUG #18070: Assertion failed when processing error from plpy's iterator
Дата
Msg-id ZQVm8KponTxqj8G3@paquier.xyz
обсуждение исходный текст
Ответ на Re: BUG #18070: Assertion failed when processing error from plpy's iterator  (Alexander Lakhin <exclusion@gmail.com>)
Ответы Re: BUG #18070: Assertion failed when processing error from plpy's iterator  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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

Вложения

В списке pgsql-bugs по дате отправления:

Предыдущее
От: Alexander Lakhin
Дата:
Сообщение: Re: BUG #17928: Standby fails to decode WAL on termination of primary
Следующее
От: PG Bug reporting form
Дата:
Сообщение: BUG #18114: FULL JOIN is replaced by LEFT JOIN in plan