Re: copying perms to another user

From: "Ross J(dot) Reedstrom" <reedstrm(at)rice(dot)edu>
To: Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Rod Taylor <rbt(at)rbt(dot)ca>, Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: copying perms to another user
Date: 2003-01-14 17:43:45
Message-ID: 20030114174345.GB15103@wallace.ece.rice.edu
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Jan 14, 2003 at 12:23:59PM +0800, Christopher Kings-Lynne wrote:
> > "Christopher Kings-Lynne" <chriskl(at)familyhealth(dot)com(dot)au> writes:
> > > No, I mean that we don't drop the user. You go:
> > > ALTER USER chriskl COPY PERMISSIONS FROM blah;
> >
> > That seems cleaner to me than the DROP thingy.
> >
> > You could only easily implement this in the current database --- but
> > since it's not a DROP, one could repeat it in each database as needed.
>
> Could someone perhaps add it to TODO then (so I don't forget about it)? I
> can't promise that I can implement it...

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;

Hmm, in fact, I can imagine uses for both forms: creating a 'template'
user who you COPY PERMISSIONS FROM when creating a new user of that type,
who will then be customized, so you can't use GROUPs. Hmm, what about
GROUP membership? Those get copied as well?

Ross

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Lincoln Yeoh 2003-01-14 17:51:56 Re: time to restore a database
Previous Message scott.marlowe 2003-01-14 17:35:07 Re: Server error and deadlocks