Dave, all:
> This issue has come up before, and I opposed it then when the interfaces
> were removed from the main tarball.
> I really don't see the upside to reducing the size of the tarball at the
> expense of ease of use. ÂSeems to me we are
> bending over backwards to make it easy for people with dial up
> connections to download our "enterprise class"
> database.
Small tarball size isn't the *primary* reason for having our
"push-it-out-to-pgFoundry" attitude, it's the *tertiary* reason. The main
two reasons are:
1) If we start including everything that's "useful", where do we stop? There
are enough pg add-ins to fill a CD -- 200 projects on GBorg and pgFoundry and
others elsewhere. And some of them probably conflict with each other. Any
decision to include some projects and not others will alienate people and
possibly be a mis-evaluation; the libpq++/libpqxx mistake comes to mind.
2) As long as we're using CVS, the only way to organize autonomous project
teams that have authority over their special areas but no ability to change
central code is to "push out" projects to separate CVS trees.
>From my perspective, putting together a coherent "distribution" of PostgreSQL
with all the add-ins you want is the job of commercial distributors and
possibly OSS projects like Bizgres.
--
--Josh
Josh Berkus
Aglio Database Solutions
San Francisco
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
