Russell Smith wrote: > Alvaro Herrera wrote: > >Jeff Davis wrote: > > > > > >>CREATE ROLE test_role > >> NOSUPERUSER INHERIT NOCREATEDB NOCREATEROLE; > >> > >>CREATE ROLE invalid_grantor > >> SUPERUSER INHERIT NOCREATEDB NOCREATEROLE; > >> > >>SET ROLE invalid_grantor; > >>GRANT "postgres" TO "test_role"; > >>SET ROLE postgres; > >> > >>select * from pg_roles; > >> > >>select pg_auth_members.*, ur.rolname, gr.rolname from pg_auth_members > >>LEFT JOIN pg_roles ur ON roleid = oid > >>LEFT JOIN pg_roles gr ON gr.oid = grantor; > >> > >>DROP ROLE invalid_grantor; > >> > >>select pg_auth_members.*, ur.rolname, gr.rolname from pg_auth_members > >>LEFT JOIN pg_roles ur ON roleid = oid > >>LEFT JOIN pg_roles gr ON gr.oid = grantor; > >> > >>DROP ROLE test_role; > >> > > > >The problem here is that we allowed the drop of invalid_grantor. We are > >missing a shared dependency on it. > > > So does this make a todo item? > > But this still leaves the concerns about you can currently get the > database into an invalid state that can't be dumped and restored.
Correct, which makes it a bug (==> needs fixed) rather than a todo item. We now have a problem because there may already be databases that are undumpable. We might need to provide a workaround for people with such a database. -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster