Re: [BUGS] Removing pg_auth_members.grantor (was Grantor name gets lost when grantor role dropped) - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: [BUGS] Removing pg_auth_members.grantor (was Grantor name gets lost when grantor role dropped)
Date
Msg-id 20070515202645.GM12731@alvh.no-ip.org
Whole thread Raw
In response to Re: [BUGS] Removing pg_auth_members.grantor (was Grantor name gets lost when grantor role dropped)  (Alvaro Herrera <alvherre@commandprompt.com>)
Responses Re: [BUGS] Removing pg_auth_members.grantor (was Grantor name gets lost when grantor role dropped)  (Russell Smith <mr-russ@pws.com.au>)
List pgsql-hackers
Alvaro Herrera wrote:
> Alvaro Herrera wrote:
> 
> > 2. decide that the standard is braindead and just omit dumping the
> >    grantor when it's no longer available, but don't remove
> >    pg_auth_members.grantor
> > 
> > Which do people feel should be implemented?  I can do whatever we
> > decide; if no one has a strong opinion on the matter, my opinion is we
> > do (2) which is the easiest.
> 
> Here is a patch implementing this idea, vaguely based on Russell's.

Applied to CVS HEAD, 8.2 and 8.1.

If we want to start tracking the grantor as a shared dependency, and
have REVOKE work per spec (i.e. only revoke the privileges actually
granted by the role executing REVOKE), those are separate patches (and
they should be applied only to HEAD).  This patch merely fixes the fact
that pg_dumpall failed to work for busted databases.

-- 
Alvaro Herrera                                http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.


pgsql-hackers by date:

Previous
From: Stefan Kaltenbrunner
Date:
Subject: Re: Not ready for 8.3
Next
From: Aidan Van Dyk
Date:
Subject: Re: Not ready for 8.3