| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
| Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, 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 15:09:27 |
| Message-ID: | 563213.1618931367@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:
> 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.
Indeed. But I'm down on this idea of inventing src/extensions,
because then there will constantly be questions about whether FOO
belongs in contrib/ or src/extensions/. Unless we just move
everything there, and then the question becomes why bother. Sure,
"contrib" is kind of a legacy name, but PG is full of legacy names.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jehan-Guillaume de Rorthais | 2021-04-20 15:17:20 | Re: when the startup process doesn't |
| Previous Message | Andrew Dunstan | 2021-04-20 15:08:48 | Re: pg_amcheck option to install extension |