Re: [PATCH] We install pg_regress and isolationtester but not pg_isolation_regress - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [PATCH] We install pg_regress and isolationtester but not pg_isolation_regress
Date
Msg-id 3809956.1602781614@sss.pgh.pa.us
Whole thread Raw
In response to Re: [PATCH] We install pg_regress and isolationtester but not pg_isolation_regress  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Responses Re: [PATCH] We install pg_regress and isolationtester but not pg_isolation_regress  (Michael Paquier <michael@paquier.xyz>)
List pgsql-hackers
Alvaro Herrera <alvherre@alvh.no-ip.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



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: [PATCH] We install pg_regress and isolationtester but not pg_isolation_regress
Next
From: Greg Sabino Mullane
Date:
Subject: psql \df choose functions by their arguments