And if this is expected correct behavior it shouldn't throw an error....
This is especially problematic for automated processes, in which you
only want to know when they fail.
Its possible to ignore error messages, but then when something real does
go wrong you lose those.
Don't get me wrong I know this is not the end of the world, but I also
think its the wrong behavior, one that is problematic for me.
Jacob
Tom Lane wrote:
"Jacob Champlin" <[EMAIL PROTECTED]> writes:
psql -f restore.sql
results in:
psql:/var/lib/pgsql/backups/restore.sql:11: ERROR: current user cannot be
dropped
psql:/var/lib/pgsql/backups/restore.sql:12: ERROR: role "postgres" already
exists
psql:/var/lib/pgsql/backups/restore.sql:17: ERROR: role "webapp" cannot be
dropped because some objects depend on it
DETAIL: access to database rief
113 objects in database rief
psql:/var/lib/pgsql/backups/restore.sql:18: ERROR: role "webapp" already
exists
And? The restore would've proceeded anyway.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs