Re: pg_amcheck option to install extension

From: Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_amcheck option to install extension
Date: 2021-04-19 16:37:18
Message-ID: 351B0755-C847-4297-BD95-3C5CDA8CD5F0@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> On Apr 19, 2021, at 9:32 AM, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
>
>
> On 4/18/21 7:32 PM, Alvaro Herrera wrote:
>> 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.
>>
>
>
> OK, so let's fix it. If amcheck is going to stay in contrib then ISTM
> pg_amcheck should move there. I can organize that if there's agreement.
> Or else let's move amcheck as Alvaro suggests.

Ah, no. I wrote pg_amcheck in contrib originally, and moved it to src/bin as requested during the v14 development cycle.


Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2021-04-19 16:41:30 Re: terminate called after throwing an instance of 'std::bad_alloc'
Previous Message Andrew Dunstan 2021-04-19 16:37:08 Re: multi-install PostgresNode fails with older postgres versions