Re: Modifying and solidifying contrib

On 1/27/07, Joshua D. Drake <jd(at)commandprompt(dot)com> wrote:
>
> Tom Lane wrote:
> > "Joshua D. Drake" <jd(at)commandprompt(dot)com> writes:
> >> So what are we thinking here? Along with my suggestion of extensions /
> >> contrib that we modify initdb to load an extensions schema with all
> >> extensions into template1?
> >
> > No, I don't think so. If you do that it's effectively moving all that
> > stuff into core, especially if you haven't provided a way to turn it
> off.
>
> O.k. any thoughts there? What if we didn't make the extensions schema
> PUBLIC? Meaning that explicits rights would have to be given for the
> extensions to be used by anyone but a super user?
>
> Obviously the initdb switch could also be selective:
>
> initdb --enable-extensions
>
> ?
>
> Sincerely,
>
> Joshua D. Drake
>
>
>
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