Re: One Role, Two Passwords

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

In response to

Browse pgsql-hackers by date

  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