From: | Florian Pflug <fgp(at)phlo(dot)org> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Josh Berkus <josh(at)agliodbs(dot)com>, Daniel Farina <drfarina(at)acm(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: One Role, Two Passwords |
Date: | 2011-01-21 02:15:18 |
Message-ID: | 251F68CC-F55C-4722-BF48-D1FC30091418@phlo.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Jan21, 2011, at 03:03 , Robert Haas wrote:
> It strikes me that it would be useful to have a GUC that sets the
> owner of any new objects you create (much as you can control their
> default schemas using search_path). Obviously, you'd need to restrict
> it so that it wouldn't allow you to create an object owned by a role
> to which you couldn't have given an object owned by yourself.
We could simply refuse to set default_owner to a rule the current user
don't inherit from. If set via an ALTER DATABASE SET ROLE the setting
would then simply be (silently) ignored - or at least this is how it
work for ALTER DATABASE SET ROLE.
> But
> this is what Florian was trying to get at with his much-maligned ALTER
> DATABASE .. SET ROLE, I think, and it seems to me that it would help
> with this case, too.
It's *precisely* what I was trying to get at! Great idea!
It seems to avoid most of the issues people had with my ALTER DATABASE
SET ROLE trick, too.
> It's always struck me that using multiple
> database logins would create all sorts of inconsistencies with
> different objects ending up owned by different users, but I guess
> until recently I was under the impression I was the only one who had
> an issue with that. It seems not.
Certainly not :-)
best regards,
Florian Pflug
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2011-01-21 02:16:43 | Re: ToDo List Item - System Table Index Clustering |
Previous Message | Daniel Farina | 2011-01-21 02:14:22 | Re: One Role, Two Passwords |