Re: [Gnumed-devel] bootstrap_db

[Karsten Hilbert]

> It probably depends on the status of ON_ERROR_STOP; if it is not set, psql 
> just prints the error messages but does not bail out with an error code (my 
> guess)
Sort of, yes. I wrestled with this and the vagaries of
popen2.Popen3() for the last 3 days.

Ultimately, bootstrap* is blocking on reading the pipe to psql
due to psql being linked against C stdio which switches from
line-buffered to block-buffered I/O when it detects that it talks
to a pipe instead of a tty. At least that's the most likely
explanation I can come up with. So I had to revert to using
os.system() to call psql.

Main problem with this: For now one will have to type in the
gm-dbowner password for each sql file being passed to psql via
os.system() unless gm-dbowner is marked "trust" in pg_hba.conf
(which should _not_ be the case). It would be an option to do

 os.system('echo "the-password" | psql ...')

which would, however, prevent us from getting the true exit
code of psql by masking it with the exit code of echo being
successfull... Another less desirable option would be to dump
the password to a temp file and go

 os.system('psql ... < the-temp-pwd-file')

which, however, is prone to security risks.

Sigh.

At least it now works and will appear in CVS in about 2 hours.

Oh, and ON_ERROR_STOP does play a role, too: When psql is
called non-interactively (say, not talking to a tty) then

 \unset ON_ERROR_STOP

becomes the default. And, get this: Unless you reenable

 \set ON_ERROR_STOP 1
 
explicitely psql _won't_ fail with exit code 3 on SQL
malformation ... |-(

At least that's what that docs say. It shows, too.

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