Re: Adjust pg_regress output for new long test names

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>
Cc: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Adjust pg_regress output for new long test names
Date: 2021-06-09 20:31:53
Message-ID: CA+TgmoY6rGMrs3KhKBdZd6awc-twcKC+Q=bQdKKW8jOE_iHhcw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Jun 9, 2021 at 1:37 PM Peter Eisentraut
<peter(dot)eisentraut(at)enterprisedb(dot)com> wrote:
> Can we scan all the test names first and then pick a suitable length?

FWIW, I think this discussion of shortening the test case names is
probably going in the wrong direction. It's true that in many cases
such a thing can be done, but it's also true that the test case
authors picked those names because they felt that they described those
test cases well. It's not unlikely that future test case authors will
have similar feelings and will again pick names that are a little bit
longer. It's also not impossible that in shortening the names we will
make them less clear. For example, Peter said that "partition" was
redundant in something like "detach-partition-concurrently-4," but
that is only true if you think that a partition is the only thing that
can be detached. That is true today as far as the SQL grammar is
concerned, but from a source code perspective we speak of detaching
from shm_mq objects or DSMs, and there could be more things, internal
or SQL-visible, in the future.

Now I don't care all that much; this isn't worth getting worked up
about. But if it were me, I'd tend to err in the direction of
accommodating longer test names, and only shorten them if it's clear
that someone *really* went overboard.

--
Robert Haas
EDB: http://www.enterprisedb.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2021-06-09 20:45:32 Re: pg14b1 stuck in lazy_scan_prune/heap_page_prune of pg_statistic
Previous Message Jonathan S. Katz 2021-06-09 20:24:27 Re: unnesting multirange data types