On Thu, Jan 20, 2011 at 8:32 PM, Josh Berkus <josh@agliodbs.com> wrote:
>
>> * Eventual Retirement of old credentials without having to issue ALTER
>> statements (or really statements of any kind...) against application
>> schema objects.
>
> OK, that's a different goal. You want to be able to expire passwords
> with an overlap period. That's quite different from wanting an
> indefinfite number of passwords per role.
>
> Mind you, the main way to do this right now ... and where you're going
> to get pushback ... is using LDAP, ActiveDirectory or similar. At a
> certain point we have to draw the line and say "PostgreSQL is not an
> authtenication server". I don't know exactly where that line is, but
> recognize that you're arguing about where to draw it.
Bingo. I think it would be great to integrate with some external
authentication solution that would support this, but I'm not that keen
on supporting it in the server - not because I don't think it's
useful, but because I think there are 20 other equally weird, equally
useful things that someone might want to do in the alternative, and I
think it'll be unmanageable to try to support them all. And next year
someone will think of another 20.
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. 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 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.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
