Обсуждение: Re: [PATCH] pg_bsd_indent: improve formatting of multiline comments
On Fri, Jun 20, 2025 at 04:44:08PM +0300, Aleksander Alekseev wrote: > Hi Arseniy, > > > I tried it with the whole project and almost always it works great. > > But I noticed two cases where it works probably not as expected: > > > > 1) comments which don't have a star on each line. For example: > > file 'cube.c' > > > > before: > > /* make up a metric in which one box will be 'lower' than the other > > -- this can be useful for sorting and to determine uniqueness */ > > > > after: > > /* > > * make up a metric in which one box will be 'lower' than the other > > -- this can be useful for sorting and to determine uniqueness */ > > > > 2) comments where closing */ is on the last comment line. For example: > > file 'crypt-blowfish.c' > > > > before: > > /* This has to be bug-compatible with the original implementation, so > > * only encode 23 of the 24 bytes. :-) */ > > > > after: > > /* > > * This has to be bug-compatible with the original implementation, so > > * only encode 23 of the 24 bytes. :-) */ > > Thanks for the review. You are right, these comments shouldn't be affected. > > It's going to be simpler to modify pgindent then. PFA the updated patch. Given the quality of BSD indent code, I have _always_ found it easier to modify pgindent. ;- -- Bruce Momjian <bruce@momjian.us> https://momjian.us EDB https://enterprisedb.com Do not let urgent matters crowd out time for investment in the future.
On Fri, Jun 20, 2025 at 05:01:41PM +0300, Aleksander Alekseev wrote: > Hi, > > > Given the quality of BSD indent code, I have _always_ found it easier to > > modify pgindent. ;- > > :D Initially I thought that the problem was simple enough to solve it > in C, but this turned out not to be true. I always found it ironic that a tool designed to make source code easier to understand like BSD indent is so hard to understand. Its use of short variable names alone is confusing. -- Bruce Momjian <bruce@momjian.us> https://momjian.us EDB https://enterprisedb.com Do not let urgent matters crowd out time for investment in the future.
On Fri, Jun 20, 2025 at 5:01 PM Aleksander Alekseev
<aleksander@timescale.com> wrote:
>
> Hi,
>
> > Given the quality of BSD indent code, I have _always_ found it easier to
> > modify pgindent. ;-
>
> :D Initially I thought that the problem was simple enough to solve it
> in C, but this turned out not to be true.
>
> > It's going to be simpler to modify pgindent then. PFA the updated patch.
>
> I noticed a mistake in v2. Here is the corrected patch. Changes
> comparing to the previous version:
>
Thanks!
Now it affects 4 times more files (380). What I noticed:
1) Most of the comments are bordered comments like this:
-/* --------------------------------------------------------------------------------
+/*
+ * --------------------------------------------------------------------------------
* Public IO related functions operating on IO Handles
* --------------------------------------------------------------------------------
*/
Do we want to skip such comments?
I have also seen comments with '====' border.
2) Some comments like this:
before:
/* Author: Linus Tolke
(actually most if the code is "borrowed" from the distribution and just
slightly modified)
*/
after:
/*
* Author: Linus Tolke
(actually most if the code is "borrowed" from the distribution and just
slightly modified)
*/
I guess closing */ on the separate line is the trigger?
If I'm not wrong there are only 3 such comments, maybe it is easier to
fix them by hand?)
3) It seems all geqo related file contains such comment:
-/* contributed by:
+/*
+ * contributed by:
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
* Martin Utesch * Institute of
Automatic Control *
=
Best regards,
Arseniy Mukhin
On Mon, Jun 23, 2025 at 01:42:32PM +0300, Aleksander Alekseev wrote: >> Do we want to skip such comments? >> I have also seen comments with '====' border. > > Personally I don't have a strong opinion on this. We can easily add an > exception for "/* ---" and "/* ===" comments if somebody believes this > is a problem. I choose not to add such an exception just yet only > because I don't like unnecessary exceptions :) +1 for adding an exception for "/* -----" style comments. I tested running pgindent after applying the patch, and the first thing I noticed was all these (IMHO) unnecessary changes. I don't think it helps readability, and even if it did, it's arguably not worth the churn. -- nathan
Hi Nathan, > > Personally I don't have a strong opinion on this. We can easily add an > > exception for "/* ---" and "/* ===" comments if somebody believes this > > is a problem. I choose not to add such an exception just yet only > > because I don't like unnecessary exceptions :) > > +1 for adding an exception for "/* -----" style comments. I tested running > pgindent after applying the patch, and the first thing I noticed was all > these (IMHO) unnecessary changes. I don't think it helps readability, and > even if it did, it's arguably not worth the churn. OK, here is the corrected patch v5. -- Best regards, Aleksander Alekseev
Вложения
On Mon, Oct 27, 2025 at 03:13:33PM +0300, Aleksander Alekseev wrote: > OK, here is the corrected patch v5. Thanks. I had to run pgindent twice before it stopped making changes, but the results look pretty good to me. However, I still noticed a few oddities. --- a/contrib/seg/seg.c +++ b/contrib/seg/seg.c @@ -2,9 +2,9 @@ * contrib/seg/seg.c * ****************************************************************************** - This file contains routines that can be bound to a Postgres backend and - called by the backend in the process of processing queries. The calling - format for these routines is dictated by Postgres architecture. + * This file contains routines that can be bound to a Postgres backend and + * called by the backend in the process of processing queries. The calling + * format for these routines is dictated by Postgres architecture. ******************************************************************************/ This one is a little weird, but maybe it's okay... It looks like pgindent retains the spacing (or lack of spacing) in this situation. It's probably not worth the complexity to try to make it smarter here. --- a/src/backend/access/nbtree/nbtsort.c +++ b/src/backend/access/nbtree/nbtsort.c @@ -69,7 +69,7 @@ /* * DISABLE_LEADER_PARTICIPATION disables the leader's participation in * parallel index builds. This may be useful as a debugging aid. -#undef DISABLE_LEADER_PARTICIPATION + *#undef DISABLE_LEADER_PARTICIPATION */ IMHO we should either remove this line or move it out of the comment. AFAICT we ordinarily don't #undef debugging stuff like this, presumably so you can change it with compile flags. In aclcheck.c and analyze.c, The **** and ==== lines are still getting bumped down to a new line. -.* This function just encapsulates the framing rules. + *.* This function just encapsulates the framing rules. This looks like a goof in commit 25a30bb. I'll go fix that one separately. --- a/src/backend/storage/ipc/waiteventset.c +++ b/src/backend/storage/ipc/waiteventset.c @@ -2010,7 +2010,7 @@ ResOwnerReleaseWaitEventSet(Datum res) * NB: be sure to save and restore errno around it. (That's standard practice * in most signal handlers, of course, but we used to omit it in handlers that * only set a flag.) XXX - * + * * This one looks like a goof in commit 393e0d2. It's interesting that pgindent chooses to add an extra * here, though. -- nathan
On Mon, Oct 27, 2025 at 09:55:38AM -0500, Nathan Bossart wrote: > /* > * DISABLE_LEADER_PARTICIPATION disables the leader's participation in > * parallel index builds. This may be useful as a debugging aid. > -#undef DISABLE_LEADER_PARTICIPATION > + *#undef DISABLE_LEADER_PARTICIPATION > */ > > IMHO we should either remove this line or move it out of the comment. > AFAICT we ordinarily don't #undef debugging stuff like this, presumably so > you can change it with compile flags. I would put this one on a separate line, outside the comment. It's minor, still we use this style in pg_config_manual.h. See around REALLOCATE_BITMAPSETS. -- Michael
Вложения
> On Oct 28, 2025, at 07:35, Michael Paquier <michael@paquier.xyz> wrote: > > On Mon, Oct 27, 2025 at 09:55:38AM -0500, Nathan Bossart wrote: >> /* >> * DISABLE_LEADER_PARTICIPATION disables the leader's participation in >> * parallel index builds. This may be useful as a debugging aid. >> -#undef DISABLE_LEADER_PARTICIPATION >> + *#undef DISABLE_LEADER_PARTICIPATION >> */ >> >> IMHO we should either remove this line or move it out of the comment. >> AFAICT we ordinarily don't #undef debugging stuff like this, presumably so >> you can change it with compile flags. > > I would put this one on a separate line, outside the comment. It's > minor, still we use this style in pg_config_manual.h. See around > REALLOCATE_BITMAPSETS. > -- > Michael +1 -- Chao Li (Evan) HighGo Software Co., Ltd. https://www.highgo.com/
> On Oct 27, 2025, at 20:13, Aleksander Alekseev <aleksander@tigerdata.com> wrote:
>
> Hi Nathan,
>
>>> Personally I don't have a strong opinion on this. We can easily add an
>>> exception for "/* ---" and "/* ===" comments if somebody believes this
>>> is a problem. I choose not to add such an exception just yet only
>>> because I don't like unnecessary exceptions :)
>>
>> +1 for adding an exception for "/* -----" style comments. I tested running
>> pgindent after applying the patch, and the first thing I noticed was all
>> these (IMHO) unnecessary changes. I don't think it helps readability, and
>> even if it did, it's arguably not worth the churn.
>
> OK, here is the corrected patch v5.
>
> --
> Best regards,
> Aleksander Alekseev
> <v5-0001-pgindent-improve-formatting-of-multiline-comments.patch>
1. I just ran the patched pgindent against a random file, then I got a lot diffs like:
```
/*
- * Direct advancement: avoid waking non-caught up backends that
- * aren't interested in our notifications.
+ * Direct advancement: avoid waking non-caught up backends that aren't
+ * interested in our notifications.
*/
```
I am afraid that would generate a lot of noises for future reviews.
2. A typo in the patch
```
+ # Check each line except for the fist and the last one
```
fist => first
3. As you are updating pgindent, I want to report an issue, you may address in a separate patch or just in this patch,
upto you.
See this code:
```
else
/*
* fetch all the rest of the page
*/
copysize = QUEUE_PAGESIZE - curoffset;
```
In the “else” clause, there is a multiple-line comment block, and a single line of code. Pgindent will add an empty
linebetween “else” and the comment block, which is weird. If the comment is one-line, then no empty line will be
inserted.
Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/
Hi,
> I am afraid that would generate a lot of noises for future reviews.
>
> 2. A typo in the patch
>
> ```
> + # Check each line except for the fist and the last one
> ```
Thanks, fixed.
> 3. As you are updating pgindent, I want to report an issue, you may address in a separate patch or just in this
patch,up to you.
>
> See this code:
> ```
> else
> /*
> * fetch all the rest of the page
> */
> copysize = QUEUE_PAGESIZE - curoffset;
> ```
>
> In the “else” clause, there is a multiple-line comment block, and a single line of code. Pgindent will add an empty
linebetween “else” and the comment block, which is weird. If the comment is one-line, then no empty line will be
inserted.
I didn't manage to find this code. The closest thing I see is in
src/backend/commands/async.c:
```
else
{
/* fetch all the rest of the page */
copysize = QUEUE_PAGESIZE - curoffset;
}
```
Last time it was touched 15 years ago and pgindent processes it as expected.
> 1. I just ran the patched pgindent against a random file, then I got a lot diffs like:
>
> ```
> /*
> - * Direct advancement: avoid waking non-caught up backends that
> - * aren't interested in our notifications.
> + * Direct advancement: avoid waking non-caught up backends that aren't
> + * interested in our notifications.
> */
> ```
I'm not sure if this is part of the PostgreSQL code base either. My
best guess is that something is wrong with whitespaces here (tabs vs
spaces). We have plenty of multiline comments like this and from what
I can tell they are processed correctly.
--
Best regards,
Aleksander Alekseev
Вложения
> On Nov 10, 2025, at 17:28, Aleksander Alekseev <aleksander@tigerdata.com> wrote: > >> 1. I just ran the patched pgindent against a random file, then I got a lot diffs like: >> >> ``` >> /* >> - * Direct advancement: avoid waking non-caught up backends that >> - * aren't interested in our notifications. >> + * Direct advancement: avoid waking non-caught up backends that aren't >> + * interested in our notifications. >> */ >> ``` > > I'm not sure if this is part of the PostgreSQL code base either. My > best guess is that something is wrong with whitespaces here (tabs vs > spaces). We have plenty of multiline comments like this and from what > I can tell they are processed correctly. I recalled that. I ran pgindent on a file from a patch I was reviewing, so, the file was not pgindent-ed yet at the time. I just tried to run the patched pgindent on several files and no diff generated. So this comment is resolved. Regards, -- Chao Li (Evan) HighGo Software Co., Ltd. https://www.highgo.com/
On Tue, Oct 28, 2025 at 08:36:33AM +0800, Chao Li wrote: > On Oct 28, 2025, at 07:35, Michael Paquier <michael@paquier.xyz> wrote: >> On Mon, Oct 27, 2025 at 09:55:38AM -0500, Nathan Bossart wrote: >>> /* >>> * DISABLE_LEADER_PARTICIPATION disables the leader's participation in >>> * parallel index builds. This may be useful as a debugging aid. >>> -#undef DISABLE_LEADER_PARTICIPATION >>> + *#undef DISABLE_LEADER_PARTICIPATION >>> */ >>> >>> IMHO we should either remove this line or move it out of the comment. >>> AFAICT we ordinarily don't #undef debugging stuff like this, presumably so >>> you can change it with compile flags. >> >> I would put this one on a separate line, outside the comment. It's >> minor, still we use this style in pg_config_manual.h. See around >> REALLOCATE_BITMAPSETS. > > +1 Here's a patch for this. I also changed the #undefs to #defines. -- nathan
Вложения
With the latest patch applied, I'm still seeing problems with **** and ==== lines in aclcheck.c and analyze.c, as mentioned upthread [0]. I think we should also figure out what we want to do for things like this: ****************************************************************************** - This file contains routines that can be bound to a Postgres backend and - called by the backend in the process of processing queries. The calling - format for these routines is dictated by Postgres architecture. + * This file contains routines that can be bound to a Postgres backend and + * called by the backend in the process of processing queries. The calling + * format for these routines is dictated by Postgres architecture. ******************************************************************************/ Could we modify the patch to leave these kinds of comments alone? [0] https://postgr.es/m/aP-H6kSsGOxaB21k%40nathan -- nathan
Hi Nathan, > [...] > I think we should also figure out what we want to do for things like this: > > ****************************************************************************** > - This file contains routines that can be bound to a Postgres backend and > - called by the backend in the process of processing queries. The calling > - format for these routines is dictated by Postgres architecture. > + * This file contains routines that can be bound to a Postgres backend and > + * called by the backend in the process of processing queries. The calling > + * format for these routines is dictated by Postgres architecture. > ******************************************************************************/ > > Could we modify the patch to leave these kinds of comments alone? I see 3 files that have this comment: - src/tutorial/complex.c - contrib/seg/seg.c - contrib/cube/cube.c Note that cube.c is not affected by the new version of pgindent, because the comment starts with `/****`. Such comments are kept as is. seg.c and cube.c use a mixed format. The comments start with `/*` followed by ` *` lines but several lines below don't have ` *` in the beginning. I don't instantly see a way to process this situation in pgindent. We can either let it modify these comments, or alternatively change the first lines of the comments from `/*` to `/**`. -- Best regards, Aleksander Alekseev
It's strange to see this thread go on about messing with the Perl script because we're too afraid of pg_bsd_indent. Maybe we should take ownership of that code -- improve its own indentation to our conventions, add comments, rename unclear variables, and so on until we have something we can work with, and fix these weird bugs and idiosincratic behaviors we don't like. I just found out this code dates back from 1976. We have a _huge_ regression test for it: our own source code repository. It's not like any breakage is going to go unnoticed. -- Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/ "Cómo ponemos nuestros dedos en la arcilla del otro. Eso es la amistad; jugar al alfarero y ver qué formas se pueden sacar del otro" (C. Halloway en La Feria de las Tinieblas, R. Bradbury)
=?utf-8?Q?=C3=81lvaro?= Herrera <alvherre@kurilemu.de> writes:
> It's strange to see this thread go on about messing with the Perl script
> because we're too afraid of pg_bsd_indent. Maybe we should take
> ownership of that code -- improve its own indentation to our
> conventions, add comments, rename unclear variables, and so on until we
> have something we can work with, and fix these weird bugs and
> idiosincratic behaviors we don't like. I just found out this code dates
> back from 1976.
I've worked with that code a little bit, and it's mostly unreadable
spaghetti :-(. If somebody wants to make an effort to make it not
so awful, that'd be great, but I fear it's a very nontrivial project.
Having said that, we've already basically forked it from the NetBSD
upstream, so there is no reason not to diverge further.
> We have a _huge_ regression test for it: our own source code repository.
> It's not like any breakage is going to go unnoticed.
True.
regards, tom lane
On Fri, Dec 12, 2025 at 11:17:01AM -0500, Tom Lane wrote: > =?utf-8?Q?=C3=81lvaro?= Herrera <alvherre@kurilemu.de> writes: >> It's strange to see this thread go on about messing with the Perl script >> because we're too afraid of pg_bsd_indent. Maybe we should take >> ownership of that code -- improve its own indentation to our >> conventions, add comments, rename unclear variables, and so on until we >> have something we can work with, and fix these weird bugs and >> idiosincratic behaviors we don't like. I just found out this code dates >> back from 1976. > > I've worked with that code a little bit, and it's mostly unreadable > spaghetti :-(. If somebody wants to make an effort to make it not > so awful, that'd be great, but I fear it's a very nontrivial project. Yeah, I tried to find a bug in it recently and could do little more than trial-and-error in the areas that seemed vaguely close (with no success). I'm generally critical of efforts to rewrite things from scratch, but this might be a case where it's the better option. -- nathan
Nathan Bossart <nathandbossart@gmail.com> writes:
> Yeah, I tried to find a bug in it recently and could do little more than
> trial-and-error in the areas that seemed vaguely close (with no success).
> I'm generally critical of efforts to rewrite things from scratch, but this
> might be a case where it's the better option.
There's something to be said for that approach. Presumably, a rewrite
could be smaller because we wouldn't need to support all the options
bsd_indent has, just the behavior PG wants.
I wonder whether it'd be possible to get rid of the need for
typedefs.list while at it. That might be impractical --- IIRC, C
syntax is ambiguous if you don't know which identifiers are typedefs.
Still, I believe there are other indenters that get away without
that knowledge, so maybe the ambiguity isn't fatal for indentation
purposes.
With or without that nice-to-have, it'd be a lot of work with
not all that much payoff, so I'm finding it hard to recommend
that somebody go after this. But maybe someone will find it
irresistible to scratch that itch.
regards, tom lane
Hi, > It's strange to see this thread go on about messing with the Perl script > because we're too afraid of pg_bsd_indent. Maybe we should take > ownership of that code -- improve its own indentation to our > conventions, add comments, rename unclear variables, and so on until we > have something we can work with, and fix these weird bugs and > idiosincratic behaviors we don't like. I just found out this code dates > back from 1976. > With or without that nice-to-have, it'd be a lot of work with > not all that much payoff, so I'm finding it hard to recommend > that somebody go after this. But maybe someone will find it > irresistible to scratch that itch. I was thinking just recently that rewriting pgindent in Python might be a good idea for future refactoring, but probably only if and after we merge PyTest patchset [1]. (Which strangely enough is missing on the nearest open commitfest.) [1]: https://www.postgresql.org/message-id/flat/CAOYmi%2BkThkM9Z87u%3DR_Wi7fCor2i%2BUZKAyq0UCyprzCwTQvqgA%40mail.gmail.com -- Best regards, Aleksander Alekseev
On Fri, Dec 12, 2025 at 11:17:01AM -0500, Tom Lane wrote: > =?utf-8?Q?=C3=81lvaro?= Herrera <alvherre@kurilemu.de> writes: > > It's strange to see this thread go on about messing with the Perl script > > because we're too afraid of pg_bsd_indent. Maybe we should take > > ownership of that code -- improve its own indentation to our > > conventions, add comments, rename unclear variables, and so on until we > > have something we can work with, and fix these weird bugs and > > idiosincratic behaviors we don't like. I just found out this code dates > > back from 1976. > > I've worked with that code a little bit, and it's mostly unreadable > spaghetti :-(. If somebody wants to make an effort to make it not > so awful, that'd be great, but I fear it's a very nontrivial project. Yes, this is why we had to wrap the pg_bsd_indent call in Perl. -- Bruce Momjian <bruce@momjian.us> https://momjian.us EDB https://enterprisedb.com Do not let urgent matters crowd out time for investment in the future.