Re: pgindent vs variable declaration across multiple lines

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
Cc: Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: pgindent vs variable declaration across multiple lines
Date: 2023-01-22 22:34:52
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Thomas Munro <thomas(dot)munro(at)gmail(dot)com> writes:
> On Fri, Jan 20, 2023 at 2:43 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> 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 seems to be (stangely) in io.c:

> ps.ind_stmt = ps.in_stmt & ~ps.in_decl; /* next line should be
> * indented if we have not
> * completed this stmt and if
> * we are not in the middle of
> * a declaration */

> If you just remove "& ~ps.in_decl" then it does the desired thing for
> that new code in predicate.c, but it also interferes with declarations
> with commas, ie int i, j; where i and j currently line up, now j just
> gets one indentation level. It's probably not the right way to do it
> but you can fix that with a last token kluge, something like:
> #include "indent_codes.h"
> ps.ind_stmt = ps.in_stmt && (!ps.in_decl || ps.last_token != comma);
> That improves a lot of code in our tree IMHO but of course there is
> other collateral damage...

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: ps.block_init is true within such an expression,
and then ps.block_init_level is the brace nesting depth inside it.
If you just enable ind_stmt based on block_init then you get a bunch
of unwanted additional indentation inside struct initializers, but
it seems to work okay if you restrict it to not happen inside braces.
More importantly, it doesn't change anything we don't want changed.

Proposed patch for pg_bsd_indent attached. 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 change that we'd like it to.

regards, tom lane

Attachment Content-Type Size
pgindent.patch text/x-diff 957 bytes
resulting-changes.diff text/x-diff 73.4 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2023-01-22 22:38:06 Re: run pgindent on a regular basis / scripted manner
Previous Message Justin Pryzby 2023-01-22 22:27:51 Re: Remove source code display from \df+?