On Sat, Nov 24, 2012 at 8:41 PM, Chris Travers <chris.travers@xxxxxxxxx> wrote: > 2) PostgreSQL allows you to move this authentication to a secondary service > like Kerberos, LDAP, or anything PAM supported. This means that if you want > to you can use a dedicated password store for the passwords which is not > accessible inside your database at all. Drawing a side point from this comment. We have some pieces of information that are global and public (basic configs and stuff), some that are private to one particular client's login, and some that are admin-only. Ideally, I'd like to have them all stored in one PG database, because some of them interact (eg there'll be joins involving the current client's info in table X and the public info in table Y). Currently, we're doing the same as the OP, with application-defined security based on a table of hashed passwords. Is there a way to arrange security such that this can be done efficiently? There are quite a few cases when public information is needed and a client's login isn't yet available, and I'd rather not have to connect using a public-only login, then disconnect and reconnect when we have the user's credentials. ChrisA -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
