Re: [PATCH] We install pg_regress and isolationtester but not pg_isolation_regress

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
Cc: Craig Ringer <craig(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: [PATCH] We install pg_regress and isolationtester but not pg_isolation_regress
Date: 2020-10-15 17:06:54
Message-ID: 3809956.1602781614@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> writes:
> I forgot to mention that I considered backpatching this and decided not
> to, but only because it might confuse packagers if they see unrecognized
> files in the installation. I realize now that c3a0818460a8 was
> back-patched. Any opinions on backpatching?

We've added new installed files in minor releases before, true.
But I agree it's something to do only when pretty important, and I'm
not sure this clears the bar. TAP tests (the facility added by that
other patch) seem way more commonly useful than isolation tests.

Quickly counting the uses in our existing in-core extensions, I see

TAP_TESTS: 3 contrib, 5 src/test/modules
ISOLATION: 1 contrib, 3 src/test/modules

Other than src/test/modules/brin, the ISOLATION users don't look
much like real extensions (rather than test scaffolding), either.
If you discount test scaffolding modules then the use-counts are
more like 4 to 1.

So I'm -0.1 or so on backpatching.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Sabino Mullane 2020-10-15 17:21:06 psql \df choose functions by their arguments
Previous Message Alvaro Herrera 2020-10-15 16:47:36 Re: [PATCH] We install pg_regress and isolationtester but not pg_isolation_regress