On 4/19/21 1:25 PM, Mark Dilger wrote: > >> 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.
There are at least two other client side programs in contrib. So this argument doesn't quite hold water from a consistency POV. > >> 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. > I missed that, so I guess maybe I can't complain too loudly. But if I'd seen it I would have disagreed. :-) cheers andrew -- Andrew Dunstan EDB: https://www.enterprisedb.com
