Re: moving from contrib to bin

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: moving from contrib to bin
Date: 2014-12-12 16:40:39
Message-ID: CA+Tgmob5q4rUP3PaUOC9ieknC6JZ=X0GYqa9vyJB=FDXZcr6DQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Dec 12, 2014 at 11:26 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> I'm not really convinced this is a very good idea. What do we get out
>> of moving everything, or even anything, from contrib? It will make
>> back-patching harder, but more importantly, it will possibly create
>> the false impression that everything we distribute is on equal
>> footing. Right now, we've got stuff like vacuumlo in contrib which is
>> useful but, let's face it, also a cheap hack. If we decide that
>> executables can no longer live in contrib, then every time somebody
>> submits something in the future, we've got to decide whether it
>> deserves parity with psql and pg_dump or whether we shouldn't include
>> it at all. contrib is a nice middle-ground.
>
> Yeah, that's a good point. I think part of the motivation here is the
> thought that some of these programs, like pg_upgrade, *should* now be
> considered on par with pg_dump et al. But it does not follow that
> everything in contrib is, or should be, on that level.

Yeah. We have put enough effort collectively into pg_upgrade that I
think it's fair to say that it is on a part with pg_dump. I still
think the architecture there is awfully fragile and we should try to
improve it, but it's very widely-used and people rely on it to work,
which it generally does. And certainly we have put a lot of sweat
into making it work.

I would also say that pg_archivecleanup is a fundamental server tool
and that it belongs in src/bin.

But after that, I get fuzzy. For me, the next tier of things would
consist of pgbench, pg_test_fsync, pg_test_timing, and pg_xlogdump.
Those are all useful, but I would also classify them as optional. If
you are running a PostgreSQL installation, you definitely need initdb
and postgres and pg_dump and pg_dumpall and psql, but you don't
definitely need these. I think they are all robust enough to go in
src/bin, but they are not as necessary as much of the stuff that is in
that directory today, so it's unclear to me whether we want to put
them there.

Finally, there is the stuff that is either hacky or deprecated:
oid2name, pg_standby, vacuumlo. Putting that stuff in src/bin clearly
makes no sense IMV. But I wouldn't necessarily want to remove it all
either.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2014-12-12 16:42:57 Re: moving from contrib to bin
Previous Message Andres Freund 2014-12-12 16:40:05 Re: moving from contrib to bin