Now that pg_bsd_indent is in our tree, we can format this as a
patch against Postgres sources. I'll stick it in the March CF
so we don't forget about it.
regards, tom lane
diff --git a/src/tools/pg_bsd_indent/args.c b/src/tools/pg_bsd_indent/args.c
index
Andrew Dunstan writes:
> On 2023-01-22 Su 17:34, Tom Lane wrote:
>> I've also attached a diff
>> representing the delta between what current pg_bsd_indent wants to do
>> to HEAD and what this would do. All the changes it wants to make look
>> good, although I can't say whether there are other
On 2023-01-22 Su 17:34, Tom Lane wrote:
> I've also attached a diff
> representing the delta between what current pg_bsd_indent wants to do
> to HEAD and what this would do. All the changes it wants to make look
> good, although I can't say whether there are other places it's failing
> to
On Mon, Jan 23, 2023 at 11:34 AM Tom Lane wrote:
> I spent some more time staring at this and came up with what seems like
> a workable patch, based on the idea that what we want to indent is
> specifically initialization expressions. pg_bsd_indent does have some
> understanding of that:
Hi,
On 2023-01-22 17:34:52 -0500, Tom Lane wrote:
> I spent some more time staring at this and came up with what seems like
> a workable patch, based on the idea that what we want to indent is
> specifically initialization expressions.
That's awesome. Thanks for doing that.
> Proposed patch
Thomas Munro writes:
> On Fri, Jan 20, 2023 at 2:43 PM Tom Lane wrote:
>> Yeah :-(. That's enough of a rat's nest that I've not really wanted to.
>> But I'd support applying such a fix if someone can figure it out.
> This may be a clue: the place where declarations are treated
> differently
On Fri, Jan 20, 2023 at 2:43 PM Tom Lane wrote:
> Andres Freund writes:
> > There's a few places in the code that try to format a variable definition
> > like this
>
> > ReorderBufferChange *next_change =
> > dlist_container(ReorderBufferChange, node, next);
>
> > but pgindent turns
On Thu, Jan 19, 2023 at 8:31 PM Andres Freund wrote:
> I know I can leave the variable initially uninitialized and then do a separate
> assignment, but that's not a great fix.
That's what I do.
If you pick names for all of your data types that are very very long
and wordy then you don't feel as
Hi,
On 2023-01-19 17:59:49 -0800, Andres Freund wrote:
> On 2023-01-19 20:43:44 -0500, Tom Lane wrote:
> > Andres Freund writes:
> > > There's a few places in the code that try to format a variable definition
> > > like this
> >
> > > ReorderBufferChange *next_change =
> > >
Andres Freund writes:
> On 2023-01-19 20:43:44 -0500, Tom Lane wrote:
>> What reindent-all-branches pain? We haven't done an all-branches
>> reindent in the past, even for pgindent fixes that touched far more
>> code than this would (assuming that the proposed fix doesn't have
>> other
Hi,
On 2023-01-19 20:43:44 -0500, Tom Lane wrote:
> Andres Freund writes:
> > There's a few places in the code that try to format a variable definition
> > like this
>
> > ReorderBufferChange *next_change =
> > dlist_container(ReorderBufferChange, node, next);
>
> > but pgindent
Andres Freund writes:
> There's a few places in the code that try to format a variable definition
> like this
> ReorderBufferChange *next_change =
> dlist_container(ReorderBufferChange, node, next);
> but pgindent turns that into
> ReorderBufferChange *next_change =
>
Hi,
There's a few places in the code that try to format a variable definition like
this
ReorderBufferChange *next_change =
dlist_container(ReorderBufferChange, node, next);
but pgindent turns that into
ReorderBufferChange *next_change =
dlist_container(ReorderBufferChange,
13 matches
Mail list logo
