Re: Unsupported 3rd-party solutions (Was: Few questions

In an attempt to throw the authorities off his trail, tgl@sss.pgh.pa.us (Tom Lane) transmitted:
> Thomas Hallgren <thhal@mailblocks.com> writes:
>> ... My suggestion is not that you take on more work but
>> rather that the comittee is allowed to grow and take on responsabilities
>> and people beyond the developers of the core database.
>
> Enlarging the core committee by the amount you seem to be thinking of
> would transform it into something quite different than it is now
> (in particular it would be too large to make decisions effectively,
> IMHO).  And I don't see that it actually accomplishes anything.
>
> The real issue here is finding someone to do the work --- it's notable
> that this thread has been going on for some time now and no one has
> actually stepped up and volunteered to *do* anything.  I think if there
> were someone out there willing to do it, they could and would do it,
> with or without core's blessing.

It seems to me that some vital components have already been set up,
considering:

 a) pgxs provides a "build environment" to make it easier to add in
    "third party extensions" without each of them having to have its
    own full PG source tree.

 b) PGFoundry is getting set up as a hopefully-decent place to host
    things that would be likely to fit into that "second tier" of
    "Extensions that ought to be ubiquitous."

Those can also play off against each other; for an extension to become
"ubiquitous," it is only reasonable for its developers to improve the
builds to make them play well with pgxs.

The way I can see this head is for there to be a significant
population of projects on PGFoundry that, by virtue of using pgxs,
become as easy to add in as most of the contrib items are now, and
perhaps roughly as easy as the average BSD Port.

I did both a Solaris and AIX build today, and threw in a whole barrel
of contrib modules via the simple statement:

for module in pg_autovacuum oid2name pgstattuple pgcrypt [and more...] ; do
   cd $module
   make clean
   make install
   cd ..
done

If there were 35 projects on PGFoundry set up in much this way,
perhaps more in the BSD Ports style, where I can pull down a tarball
with 35 directories, and then set things up...

$ export http_proxy=http://cache.myhost.example.info:3128/
$ exPGCONFIG=`/usr/local/lib/pgsql801/bin/pg_config --configure`
$ PGDEPLOY=/tmp/pgfoundry
$ cd /usr/local/src/pgfoundry
$ for module in PGF*; do
  cd $module; make install; cd ..
done

The "make install" would download the _real_ sources, via the
requested HTTP proxy, run "make" on each one, using the PostgreSQL
backend configuration specified in $PGCONFIG, and then

That's the sort of thing that _also_ makes it pretty easy for package
management folk to bundle it up ready for integration tests.  There
are tools for both Red Hat-style RPM's and Debian .deb's that
specifically pull modules from Perl's CPAN site, by name, and then
bundle them into packages.

This doesn't "magically" solve all systems integration problems, but
it sure seems likely to go a long way to help.
--
let name="cbbrowne" and tld="acm.org" in name ^ "@" ^ tld;;
http://cbbrowne.com/info/advocacy.html
Users should cultivate an ability to make the simplest molehill into a
mountain   by   finding   controversial interpretations   of innocuous
sounding statements that the sender never intended or imagined.
-- from the Symbolics Guidelines for Sending Mail