Re: pg_amcheck option to install extension
От | Mark Dilger |
---|---|
Тема | Re: pg_amcheck option to install extension |
Дата | |
Msg-id | 351B0755-C847-4297-BD95-3C5CDA8CD5F0@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: pg_amcheck option to install extension (Andrew Dunstan <andrew@dunslane.net>) |
Ответы |
Re: pg_amcheck option to install extension
|
Список | pgsql-hackers |
> On Apr 19, 2021, at 9:32 AM, Andrew Dunstan <andrew@dunslane.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
В списке pgsql-hackers по дате отправления: