On Fri, Dec 12, 2014 at 11:26 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
