> On Apr 19, 2021, at 9:53 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> 
> Andrew Dunstan <and...@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-client and postgresql-contrib are 
separate rpms.  There isn't much point to having pg_amcheck installed as part 
of 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 system makes sense if you are 
connecting to a server on a different system.

> On Mar 11, 2021, at 12:12 AM, Peter Eisentraut 
> <peter.eisentr...@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 should be 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





Reply via email to