Re: pg_amcheck option to install extension

From: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_amcheck option to install extension
Date: 2021-04-20 14:51:40
Message-ID: 20210420145140.GA2451@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2021-Apr-20, Michael Paquier wrote:

> Agreed. Something like src/extensions/ would be a tempting option,
> but I don't think that it is a good idea to introduce a new piece of
> infrastructure at this stage, so moving both to contrib/ would be the
> best balance with the current pieces at hand.

Actually I think the best balance would be to leave things where they
are, and move amcheck to src/extensions/ once the next devel cycle
opens. That way, we avoid the (pretty much pointless) laborious task of
moving pg_amcheck to contrib only to move it back on the next cycle.

What I'm afraid of, if we move pg_amcheck to contrib, is that during the
next cycle people will say that they are both perfectly fine in contrib/
and so we don't need to move anything anywhere. And next time someone
wants to create a new extension that would be perfectly fine in core,
they will not want to have that one be the one that creates
src/extensions/, because then that in itself is a contentious point that
can get the whole patch rejected.

In a sense, what I'm doing is support the idea that "incremental
development" applies to procedure too.

--
Álvaro Herrera 39°49'30"S 73°17'W

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Aleksander Alekseev 2021-04-20 14:57:55 `make check` doesn't pass on MacOS Catalina
Previous Message Tom Lane 2021-04-20 14:49:43 Re: [bug?] Missed parallel safety checks, and wrong parallel safety