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
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 |