Re: Modifying and solidifying contrib

I've been listening in on this discussion and it is closely tied to an extension that I would like to try.  The only thing holding me back is that I am still far to green on the source code to actually propose the work I would like to do.

It makes sense the you would want to include the contrib into the install, but I agree with Tom this isn't something you would want in template1.  plpgsql is not even in template1 IIRC.  It makes more sense to compile the libraries and have an activation module that can be represented in a pg_dump.  Maybe the best way to do this would be to place the SQL that modifies system catalog into a compiled library and call this as a function.  The function call could then be placed into the pg_dump if needed.

Here is where this ties into what I am working on proposing.  I have several custom C functions in a library that I need in a restore/build.  It seems like at least a couple times every year a new cluster is built and the Admin forgets to compile the custom functions.  He builds the DB and then "something doesn't work". 

The basic idea of my proposal would be to have a function that checks for the existence of C libraries.  The next piece I would need would be a mechanism for psql to halt the restore SQL script if these checks failed.  Finally I would need to add a switch to tell pg_dump to do the checks first thereby causing the restore to fail, hopefully with a nice message that clues the admin that something is wrong.

Yes all of this work so I don't get called after hours yet here I am working on the fix after hours. :-)

It seems to me like this might be useful in incorporating an extension/module/whatever into Postgres.

--
Kevin Barnard

"Great Beauty, great strength, and great Riches,
are really and truly of no great Use;
a right Heart exceeds all." -- Benjamin Franklin