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

On Sat, Sep 16, 2023 at 08:00:00PM +0300, Alexander Lakhin wrote:
> This lengthy output is similar to what we get with a recursion in plperl,
> so I don't consider this as an issue, but may be we could just check
> the length of an error message before concatenation...
>
> Please look at the v2 patch, which contains an addition to regression tests for the master.
> If you agree with this approach, I'll make patches for back branches as well...

+DETAIL:  spiexceptions.InvalidDatetimeFormat: invalid value "DD" for "DD"
+Value must be an integer.

That's the kind of things we've been doing for years in libpq.  So
even if there are no proper sentence terminations, that may be enough
for the user.

+        if (detail == NULL)
             detail = xmsg;
+        else if (xmsg != NULL) {
+            initStringInfo(&detailstr);
+            appendStringInfoString(&detailstr, xmsg);
+            appendStringInfoChar(&detailstr, '\n');
+            appendStringInfoString(&detailstr, detail);
+            detail = detailstr.data;
+        }

Perhaps it would be slightly cleaner to use a StringInfoData all the
time and rely on the presence of fmt to free the detail string?

Btw, backpatching a change in the error infrastructure does not seem a
good idea to me, as there could be applications that depend on the
existing behaviors?  It looks like we'd better just remove the
assertion in back-branches.
--
Michael