Peter Eisentraut <peter_e@gmx.net> writes:
> This snippet in pg_dumpall
> $PSQL -d template1 -At -F ' ' \
> -c "SELECT datname, usename, pg_encoding_to_char(d.encoding),
> datistemplate, datpath FROM pg_database d LEFT JOIN pg_shadow u ON (datdba
> = usesysid) WHERE datallowconn;" | \
> while read DATABASE DBOWNER ENCODING ISTEMPLATE DBPATH; do
> won't actually work if there indeed happens to be a database without a
> valid owner, because the 'read' command will take ENCODING as the dba
> name.
Oops, you're right, the read won't keep the columns straight. Come to
think of it, it would do the wrong thing for empty-string datname or
usename, too, and it's only because datpath is the last column that
we haven't noticed it doing the wrong thing on empty datpath.
Is there a more robust way of reading the data into the script?
> I guess the real question is, what should be done in this case? I think
> it might be better to error out and let the user fix his database before
> backing it up.
Possibly. The prior state of the code (before I put in the LEFT JOIN)
would silently ignore any database with no matching user, which was
definitely NOT a good idea.
I think I'd rather see a warning, though, and let the script try to dump
the DB anyway.
> (At a glance, I think pg_dump also has some problems with these sort of
> constellations.)
Yes, there are a number of places where pg_dump should be doing outer
joins and isn't. I think Tatsuo is at work on that.
regards, tom lane