Re: cleanup: Split long Makefile lists across lines and sort them

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Japin Li <japinli(at)hotmail(dot)com>, Jelte Fennema-Nio <postgres(at)jeltef(dot)nl>, Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com>, zengman <zengman(at)halodbtech(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: cleanup: Split long Makefile lists across lines and sort them
Date: 2025-12-29 03:32:02
Message-ID: 2742546.1766979122@sss.pgh.pa.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Michael Paquier <michael(at)paquier(dot)xyz> writes:
> On Sun, Dec 28, 2025 at 04:12:16AM +0000, Japin Li wrote:
>> 2. I noticed that btree_gin, btree_gist, and pgcrypto also have relatively
>> long REGRESS lists, should we also update them?

> If we think about that in terms of frequency where new test files are
> added, it seems to me that there would be more meaning to do that for
> pgcrypto, test_decoding and pgss. This is more true for the two last
> entries of this list.
> About the rest? Not so much. Still, I was surprised to see that we
> have added stuff to btree_gist recently for WITHOUT OVERLAPS, so
> perhaps there is a point there.

I think a reasonable policy for this going forward is to mop up
the stragglers when and if another test case is added to each one.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Previous Message Tom Lane 2025-12-29 03:29:16 Re: Fixing some ancient errors in hash join costing