On 05/09/2011 03:31 PM, Alvaro Herrera wrote:
> For executables we already have src/bin. Do we really need a separate
> place for, say, pg_standby or pg_upgrade?
>
There's really no executables in contrib that I find myself regularly
desperate for/angry at because they're not installed as an integral part
of the server, the way I regularly find myself cursing some things that
are now extensions. The only contrib executable I use often is pgbench,
and that's normally early in server life--when it's still possible to
get things installed easily most places. And it's something that can be
removed when finished, in cases where people are nervous about the
contrib package.
Situations where pg_standby or pg_upgrade suddenly pop up as emergency
needs seem unlikely too, which is also the case with oid2name,
pg_test_fsync, pg_archivecleanup, and vacuumlo. I've had that happen
with pg_archivecleanup exactly once since it appeared--running out of
space and that was the easiest way to make the problem go away
immediately and permanently--but since it was on an 8.4 server we had to
download the source and build anyway.
Also, my experience is that people are not that paranoid about running
external binaries, even though they could potentially do harm to the
database. Can always do a backup beforehand. But the idea of loading a
piece of code that lives in the server all the time freaks them out.
The way the word contrib implies (and sometimes is meant to mean) low
quality, while stuff that ships with the main server package does not,
has been beaten up here for years already. It's only a few cases where
that's not fully justified, and the program can easily become an
extension, that I feel are really worth changing here. There are 49
directories in contrib/ ; at best maybe 20% of them will ever fall into
that category.
--
Greg Smith 2ndQuadrant US greg@2ndQuadrant.com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.us
