Re: moving from contrib to bin

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: moving from contrib to bin
Date: 2014-12-09 03:50:30
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Peter Eisentraut <peter_e(at)gmx(dot)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

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2014-12-09 03:59:10 Re: On partitioning
Previous Message Peter Eisentraut 2014-12-09 03:26:52 moving from contrib to bin