On Thu, Jan 20, 2011 at 3:34 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Daniel Farina <drfar...@acm.org> writes: >> I wanted to test the waters on how receptive people might be to an >> extension that would allow Postgres to support two passwords for a >> given role. > > Not very. Why don't you just put two roles in the same group?
How does this work with newly created objects? Is there a way to have them default objects to a different owner, the parent of the two roles? It is highly desirable that no ALTER <OBJECT> statements should need issuing after the password transition is complete. As-is, though, I don't understand how that would be possible. It would also be nice to be able to change a password without changing the role name. In the case of password rotation, the goal would be to drop the old password after all clients have had reasonable chance to get an update. One could work around by generating new username+password pairs constantly, but there are conveniences to having a stable public-identifier for a role in addition to a private secret used to authenticate it (or, as is the case with this proposal, more than one acceptable private secrets). Changing the username all the time to facilitiate this basically renders it part of a unstable, two-part secret key, and the job of having a stable, public identifier is pushed up the application stack. -- fdr -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
