Re: Use stack-allocated StringInfoData

2025-11-06 Thread Tom Lane
=?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

Re: Use stack-allocated StringInfoData

2025-11-06 Thread David Rowley
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(

Re: Use stack-allocated StringInfoData

2025-11-06 Thread Álvaro Herrera
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 > >

Re: Use stack-allocated StringInfoData

2025-11-05 Thread Mats Kindahl
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

Re: Use stack-allocated StringInfoData

2025-11-05 Thread David Rowley
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

Re: Use stack-allocated StringInfoData

2025-11-05 Thread Chao Li
> 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

Re: Use stack-allocated StringInfoData

2025-11-05 Thread David Rowley
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

Re: Use stack-allocated StringInfoData

2025-11-04 Thread Mats Kindahl
On 11/3/25 22:32, David Rowley wrote: 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 sur

Re: Use stack-allocated StringInfoData

2025-11-03 Thread David Rowley
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

Re: Use stack-allocated StringInfoData

2025-11-03 Thread Mats Kindahl
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

Re: Use stack-allocated StringInfoData

2025-11-03 Thread David Rowley
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