From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: pgindent vs variable declaration across multiple lines |
Date: | 2023-01-20 23:12:01 |
Message-ID: | 20230120231201.5646hisbf6q5grcb@awork3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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 <andres(at)anarazel(dot)de> 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 =
> > > dlist_container(ReorderBufferChange, node, next);
> >
> > Yeah, that's bugged me too. I suspect that the triggering factor is
> > use of a typedef name within the assigned expression, but I've not
> > tried to run it to ground.
>
> It's not that - it happens even with just
> int frak =
> 1;
>
> since it doesn't happen for plain assignments, I think it's somehow related to
> code dealing with variable declarations.
Another fun one: pgindent turns
return (instr_time) {t.QuadPart};
into
return (struct instr_time)
{
t.QuadPart
};
Obviously it can be dealt with with a local variable, but ...
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2023-01-20 23:50:56 | Re: pgindent vs variable declaration across multiple lines |
Previous Message | Merlin Moncure | 2023-01-20 22:24:31 | feature request: IN clause optimized through append nodes with UNION ALL |