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
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 |