Re: moving from contrib to bin - Mailing list pgsql-hackers

From Tom Lane
Subject Re: moving from contrib to bin
Date
Msg-id 16279.1418097030@sss.pgh.pa.us
Whole thread Raw
In response to moving from contrib to bin  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: moving from contrib to bin  (Andres Freund <andres@2ndquadrant.com>)
Re: moving from contrib to bin  (Peter Eisentraut <peter_e@gmx.net>)
Re: moving from contrib to bin  ("Joshua D. Drake" <jd@commandprompt.com>)
List pgsql-hackers
Peter Eisentraut <peter_e@gmx.net> writes:
> Last time this was attempted, the discussion got lost in exactly which
> extensions are worthy enough to be considered official or something like
> that.  I want to dodge that here by starting at the opposite end:
> 1. move programs to src/bin/

> Here are the contrib programs:

> oid2name
> pg_archivecleanup
> pg_standby
> pg_test_fsync
> pg_test_timing
> pg_upgrade
> pg_xlogdump
> pgbench
> vacuumlo

> The proposal would basically be to mv contrib/$x src/bin/$x and also
> move the reference pages in the documentation.

Personally, I'm good with moving pg_archivecleanup, pg_standby,
pg_upgrade, pg_xlogdump, and pgbench this way.  (Although wasn't there
just some discussion about pg_standby being obsolete?  If so, shouldn't
we remove it instead of promoting it?)  As for the others:

I'm not exactly convinced that we want to encourage packagers to include
either pg_test_fsync or pg_test_timing in standard packages.  They are not
all that useful to ordinary users.

oid2name and vacuumlo, besides being of very dubious general utility,
are fails from a namespacing standpoint.  If we were to promote them
into standard install components I think a minimum requirement should be
to rename them to pg_something.  (oid2name is an entirely bogus name for
what it does, anyway.)  That would also be a good opportunity to revisit
their rather-ad-hoc APIs.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: moving from contrib to bin
Next
From: Amit Kapila
Date:
Subject: Re: On partitioning