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

Reply via email to