Re: pg_amcheck option to install extension - Mailing list pgsql-hackers

From Mark Dilger
Subject Re: pg_amcheck option to install extension
Date
Msg-id BBD5A9AE-2C7F-4359-B10A-113CBB538B40@enterprisedb.com
Whole thread Raw
In response to Re: pg_amcheck option to install extension  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: pg_amcheck option to install extension  (Andrew Dunstan <andrew@dunslane.net>)
List 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 by date:

Previous
From: Robert Haas
Date:
Subject: Re: Commit 86dc90056 - Rework planning and execution of UPDATE and DELETE
Next
From: Jehan-Guillaume de Rorthais
Date:
Subject: Re: multi-install PostgresNode fails with older postgres versions