Re: copying perms to another user

"Ross J. Reedstrom" <reedstrm@rice.edu> writes:
> On Tue, Jan 14, 2003 at 12:23:59PM +0800, Christopher Kings-Lynne wrote:
> "Christopher Kings-Lynne" <chriskl@familyhealth.com.au> writes:
> No, I mean that we don't drop the user.  You go:
> ALTER USER chriskl COPY PERMISSIONS FROM blah;

> In this scenario, 'blah' is the user who will eventually be dropped, and
> chriskl is taking over ownership of his 'stuff' right? How about doing it
> the other way:
> ALTER USER blah COPY PERMISSIONS TO chriskl;

That seems a bit bizarre to me.  The user whose permissions are actually
being altered by this command is chriskl, not blah, so ISTM chriskl is
the name that should be specified as being ALTERed.  In other words I
like FROM, not TO.

But: nearby, Peter E. complains that this is a poor substitute for
implementing SQL-spec roles.  He's got a point --- especially since
roles could be made installation-wide, and thus they'd get around the
problem that ALTER USER COPY couldn't realistically do anything about
permissions in other databases.  GRANT ROLE foo TO USER bar (or whatever
the spec syntax is) would be an installation-wide change and so would
indirectly grant any privileges the role has in other databases.

While I haven't thought about it very hard, it seems to me that a role
might be equivalent or nearly so to a group.  If so, we might be able
to support roles with little more than some syntactic-sugar work ...
        regards, tom lane