On Thu, Jan 20, 2011 at 8:32 PM, Josh Berkus <j...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
