回复: cleanup: Split long Makefile lists across lines and sort them - Mailing list pgsql-hackers

From Japin Li
Subject 回复: cleanup: Split long Makefile lists across lines and sort them
Date
Msg-id MEAPR01MB3031009A16B0DE41E75923CCB6BEA@MEAPR01MB3031.ausprd01.prod.outlook.com
Whole thread Raw
In response to Re: cleanup: Split long Makefile lists across lines and sort them  (Michael Paquier <michael@paquier.xyz>)
List pgsql-hackers

On Sat, Dec 27, 2025 at 08:30:59AM +0900, Michael Paquier wrote:
> On Fri, Dec 26, 2025 at 06:30:53PM +0100, Jelte Fennema-Nio wrote:
>> > If we look at existing Makefiles, they don’t add a tailing “\” in the last line of lists, so let’s keep consistent.
>>
>> Alright, attached is one without the trailing backslash. If we want to
>> add those let's indeed do it in a dedicated patch that makes all of such
>> lists consistently use them.

Expanded that to a few more SUBDIRS noticed on the way, without the
backslash after the last item of each list, and applied the result.

We have quite a few more REGRESS lists in contrib/.  Would these be
worth changing for test_decoding or pg_stat_statements at least?


I have a few questions:

1. Regarding splitting long lists: Is there an established convention or
   threshold (e.g., maximum number of items per line or maximum line length)
   that we should follow when deciding whether to break a list across multiple
   lines?

2. I noticed that btree_gin, btree_gist, and pgcrypto also have relatively
   long REGRESS lists, should we also update them?

3. Does this formatting guideline also extend to the DATA variable (for
   example in contrib Makefiles), or is it mainly intended for REGRESS lists?

--
Regards,
Japin Li
ChengDu WenWu Information Technology Co., Ltd.

pgsql-hackers by date:

Previous
From: Chengpeng Yan
Date:
Subject: Re: Add a greedy join search algorithm to handle large join problems
Next
From: Henson Choi
Date:
Subject: Re: SQL Property Graph Queries (SQL/PGQ)