Re: Multixid hindsight design

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Craig Ringer <craig(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Simon Riggs <simon(dot)riggs(at)2ndquadrant(dot)com>, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Álvaro Herrera <alvaro(dot)herrera(at)2ndquadrant(dot)com>
Subject: Re: Multixid hindsight design
Date: 2015-11-09 18:52:52
Message-ID: 30557.1447095172@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Mon, Nov 9, 2015 at 2:02 AM, Craig Ringer <craig(at)2ndquadrant(dot)com> wrote:
>> Something that'd really help with that, IMO, would be weakening the
>> requirement that everything be C or be core Perl. Instead require that
>> configure detect whether or not facilities for some tests are present,
>> and have them fail with a clean warning indicating they were skipped
>> for lack of pre-requisites at 'make' time.

> I actually kind of hate this sort of thing.

FWIW, I agree with Robert's position. Expanding the infrastructure
required for tests may make life simpler for the initial author of a test,
but we pay for that over and over again when you consider the long run.

I think insisting on having e.g. DBD::Pg is simply exporting the author's
work to other people; there isn't anything that that enables that you
can't do without it. We have added test infrastructure when there simply
wasn't any other way to test something. Both the isolation framework and
the TAP framework represent substantial investments of that sort. I'm
fine with both of those. But the bar to adding new requirements ought to
be pretty darn high, and not just "I was too lazy to write it without".

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2015-11-09 18:53:40 Re: Minor comment improvement to create_foreignscan_plan
Previous Message Pavel Stehule 2015-11-09 18:49:49 Re: proposal: PL/Pythonu - function ereport