From: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | 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-18 23:32:40 |
Message-ID: | 20210418233240.GA11048@alvherre.pgsql |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2021-Apr-18, Andrew Dunstan wrote:
> On 4/17/21 3:43 PM, Mark Dilger wrote:
> > I'd also like your impressions on whether we're likely to move
> > contrib/amcheck into core anytime soon. If so, is it worth adding
> > an option that we'll soon need to deprecate?
>
> I think if it stays as an extension it will stay in contrib. But it sure
> feels very odd to have a core bin program that relies on a contrib
> extension. It seems one or the other is misplaced.
I've proposed in the past that we should have a way to provide
extensions other than contrib -- specifically src/extensions/ -- and
then have those extensions installed together with the rest of core.
Then it would be perfectly legitimate to have src/bin/pg_amcheck that
depending that extension. I agree that the current situation is not
great.
--
Álvaro Herrera 39°49'30"S 73°17'W
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end." (2nd Commandment for C programmers)
From | Date | Subject | |
---|---|---|---|
Next Message | Justin Pryzby | 2021-04-18 23:36:15 | Re: track_planning causing performance regression |
Previous Message | Peter Geoghegan | 2021-04-18 23:27:15 | Re: partial heap only tuples |