Re: Use stack-allocated StringInfoData - Mailing list pgsql-hackers

From Álvaro Herrera
Subject Re: Use stack-allocated StringInfoData
Date
Msg-id 202511061027.6kun3grytx2d@alvherre.pgsql
Whole thread Raw
In response to Re: Use stack-allocated StringInfoData  (Mats Kindahl <mats.kindahl@gmail.com>)
Responses Re: Use stack-allocated StringInfoData
List pgsql-hackers
On 2025-Nov-06, Mats Kindahl wrote:

> On 11/5/25 12:01, David Rowley wrote:

> > It's not your fault, but check_publications_origin_tables() looks like
> > a mess. It seems like excessive use of additional code just to avoid
> > two separate ereport() calls. Might be worth a follow-up patch to
> > clean that up.
> 
> Yeah, I have noted that too, but I wanted to avoid making reviews more
> complicated than necessary. I thought it might be better to do as a separate
> effort.

Yeah, I came across this a few weeks ago as well.  I was thinking maybe
we can expand the ereport() macro instead of duplicating things.  It
looks a bit ugly and I don't think we do it anywhere else ...  I mean
something like

errstart(WARNING, NULL);
if (cond)
    errmsg( ... );
else
    errmsg( ... );
// and so on
errfinish(__FILE__, __LINE__, __func__);


Is this too ugly to live?  (I swear I had this on a branch already, but
can't find it right this instant.)

-- 
Álvaro Herrera        Breisgau, Deutschland  —  https://www.EnterpriseDB.com/
"No necesitamos banderas
 No reconocemos fronteras"                  (Jorge González)



pgsql-hackers by date:

Previous
From: Álvaro Herrera
Date:
Subject: Re: LISTEN/NOTIFY bug: VACUUM sets frozenxid past a xid in async queue
Next
From: Amit Kapila
Date:
Subject: Re: Assertion failure in SnapBuildInitialSnapshot()