Re: pg_amcheck option to install extension
От | Mark Dilger |
---|---|
Тема | Re: pg_amcheck option to install extension |
Дата | |
Msg-id | BBD5A9AE-2C7F-4359-B10A-113CBB538B40@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: pg_amcheck option to install extension (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: pg_amcheck option to install extension
|
Список | pgsql-hackers |
> On Apr 19, 2021, at 9:53 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > Andrew Dunstan <andrew@dunslane.net> writes: >> 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. > > FWIW, I think that putting them both in contrib makes the most > sense from a structural standpoint. That was my original thought also, largely from a package management perspective. Just as an example, postgresql-clientand postgresql-contrib are separate rpms. There isn't much point to having pg_amcheck installed as partof the postgresql-client package while having amcheck in the postgresql-contrib package which might not be installed. A counter argument is that amcheck is server side, and pg_amcheck is client side. Having pg_amcheck installed on a systemmakes sense if you are connecting to a server on a different system. > On Mar 11, 2021, at 12:12 AM, Peter Eisentraut <peter.eisentraut@enterprisedb.com> wrote: > > I want to register, if we are going to add this, it ought to be in src/bin/. If we think it's a useful tool, it shouldbe there with all the other useful tools. > > I realize there is a dependency on a module in contrib, and it's probably now not the time to re-debate reorganizing contrib. But if we ever get to that, this program should be the prime example why the current organization is problematic,and we should be prepared to make the necessary moves then. This was the request that motivated the move to src/bin. — Mark Dilger EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: