=?utf-8?Q?=C3=81lvaro?= Herrera writes:
> 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, NUL
On Fri, 7 Nov 2025 at 00:24, Álvaro Herrera wrote:
> 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(
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
> >
On 11/5/25 12:01, David Rowley wrote:
On Tue, 4 Nov 2025 at 21:25, Mats Kindahl wrote:
Here is an updated patch that I checked manually for unnecessary
whitespace changes.
Thanks for updating the patch.
There is one such case affected by this patch, and there the buffer
pointer is copied to a
On Thu, 6 Nov 2025 at 00:01, David Rowley wrote:
> I can push this tomorrow morning UTC+13. I'll leave it til then in
> case anyone else has any comments.
I found a few more cases that could get the same treatment and also
included the check_publications() one mentioned by Chao.
I did end up rem
> On Nov 5, 2025, at 19: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.
>
> The patch
On Tue, 4 Nov 2025 at 21:25, Mats Kindahl wrote:
> Here is an updated patch that I checked manually for unnecessary
> whitespace changes.
Thanks for updating the patch.
> There is one such case affected by this patch, and there the buffer
> pointer is copied to another variable and then returned
located StringInfo that was not necessary.
Best wishes,
Mats Kindahl
From d3a099536c3f9d47a0cb75691d5d694b0ba63ef3 Mon Sep 17 00:00:00 2001
From: Mats Kindahl
Date: Tue, 28 Jan 2025 14:09:41 +0100
Subject: Use stack-allocated StringInfoData
This uses a semantic patch to replace uses of StringInf
On Tue, 4 Nov 2025 at 09:20, Mats Kindahl wrote:
> This is using Coccinelle to transform the text based on a semantic patch
> (which is included in the patch). Unfortunately it mess with the whitespace a
> bit so it is necessary to run pg_intent after. I'm surprised that there are
> whitespace
On 11/3/25 11:27, David Rowley wrote:
On Mon, 3 Nov 2025 at 20:27, Mats Kindahl wrote:
We can use
StringInfoData info;
initStringInfo(&info);
...
appendStringInfo(&info, ...);
...
return info.data;
It was corrected in an earlier commit, but that
On Mon, 3 Nov 2025 at 20:27, Mats Kindahl wrote:
> We can use
>
>StringInfoData info;
>initStringInfo(&info);
>...
>appendStringInfo(&info, ...);
>...
>return info.data;
>
> It was corrected in an earlier commit, but that seems to have been removed s
x27;t be matched is manually fixed.
[1]:
https://www.postgresql.org/message-id/8895cba9-48cf-40fe-9c47-9b43ec6b2ab3%40gmail.com
Best wishes,
Mats Kindahl
From 7967dd042ada954dc57ddff734f4139c97cd6802 Mon Sep 17 00:00:00 2001
From: Mats Kindahl
Date: Tue, 28 Jan 2025 14:09:41 +0100
Subject: Use
12 matches
Mail list logo
