Re: [Gnumed-devel] bootstrapping needs to be more flexible ?

[Karsten Hilbert]

On Sat, Dec 24, 2005 at 04:57:04PM +0800, Syan Tan wrote:

> I'm running debian with postgresql 8.0 , and I can do a command line 
> createlang
> plpgsql gnumed_v2  if I am logged in as postgres,
> but the python script that looks for where the plpgsql lib module is inorder 
> to
> do the sql " create language plpgsql call_handler ..."
> fails, because it can't find the call handler lib.
There's a list of possible locations for the handler lib
which can be added to in the config file.

> This sql command is damn
> ugly anyway, needing to try to guess what the physical
> path is anyway,
I fully agree. However, in recent (> 7.4 ?) versions of
PostgreSQL one should use $libdir instead of a hardcoded
path which should always work. That value is the first in
the list of locations in the config file, too, hence should
almost always lead to the proper result. I'd be interested
in why it fails on your machine and what needs to be done to
fix it.

> so what about an alternate execution path for running
> createlang ?
Sure, the bootstrapper checks whether the language already
exists in the database and skips installation if so.
(Temporarily) creating the language in template1 will do
what you need to work around problems on a temporary basis.

> I still think it's absurd that the bootstrapping process doesn't check
> pg_hba.conf and postgresql.conf  for you anyway, and offer to fix it,
Because it cannot make sure it is able to edit them short of
requiring the user to know the root password. It is not at
all trivial to programmatically make the right fixes to
pg_hba/pg_ident either. It depends on site policy, actually,
which cannot be second-guessed. Dictating site policy isn't
something GNUmed should engage in as far as possible.
Anything from no security to "only run bootstrap as
postgres" is well within reasonable limits of policy a given
site may require.

> because you've got to run it as root anyway,
wrong, I haven't bootstrapped as root for literally years

> so anyone who could bootstrap  can
> easily do "su postgres" and alter /drop /create
> anything anyway.

>   I think the sql scripts should be designed to be idempotent, so you can do
> away with "set on_error_stop 1",
Being idempotent got nothing to do with the reason for "set
on_error_stop 1" as far as I can see.

This option is set because everything under it is *supposed
to work*. If not we better hear about it as soon as
possible.

> and any inserts include all values including the primary
> key value, so the bootstrapping is more robust
> and doesn't choke.
Explicitely relying on the primary key is bad style in any
case. There's no need for that either. I haven't had a
single case of failure that would have been due to a
dynamic, non-static PK statement, ever.

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