"Ross J. Reedstrom" <[EMAIL PROTECTED]> writes: > On Tue, Jan 14, 2003 at 12:23:59PM +0800, Christopher Kings-Lynne wrote: > "Christopher Kings-Lynne" <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://archives.postgresql.org