[Dbconfig-common-devel] plpgsql_call_handler

[Karsten Hilbert]

In PostgreSQL when you create a database it is templated
from the pre-existing database "template1".

Template1 is, however, also user-changeable.

So, if someone happened to install something (tables,
procedural languages) into template1 it is copied into any
new database upon "create database".

That way it is possible that someone created the function
"plpgsql_call_handler" in "template1". Then, when creating
"bulmafactserver" it is copied over to that database.
Subsequently the install script tries to install the
procedural language (plpgsql) and fails because the function
already exists. This is a bug in the "bulmafact-server
--install" bootstrapper.

> so, it sounds like when you remove the package, the plpgsql stuff isn't
> removed?  i don't know pgsql very well, but my guess is that we need to
> provide some way to perform administrative operations before the database
> is removed.  so right now we have an "install", and "install-dbadmin"
> directory, maybe we need a "uninstall-dbadmin" directory too, which
> could be executed as the dbadmin when the admin selects the "purge
> database" option during removal?
Sounds very useful.

> does that seem right?  or is it already the case that purging the
> database during package removal will fix this?
It should unless something was created in template1 because
of which it would come back to life in any newly created
database.

> > I tried to uninstall the 1.8.4 and try to isntall 1.8.3 but the problem was 
> > not solved, there still remains the same problem.
So the sequence was:

new PostgreSQL
install with 1.8.3 - success
install with 1.8.4 - failure
install with 1.8.3 - failure, too

This supports the theory that something survices purging the
database inbetween (by means of existing in template1).

This appears to be a bulmafact-server issue.

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346