----- Original Message ----- From: "Alvaro Herrera" > Donald Fraser wrote: > > > We developed and have been using since 7.1, and currently running 7.4, > > bespoke client / database software. The ability to manage users and security > > was of high priority and we therefore developed a much more elaborate user > > definition where by the information about users was held in our own tables > > and we could create a postgresql database user from this table at any time. > > To simplify things we controlled the SYSID and used this as the key for > > mapping a postgresql user to a user defined in our table. > > Why not do it the other way around? Create the Postgres user first, > grab its Oid, then use that as primary key in your user table. Read my previous posting to answer that one. The bottom line is there are several solutions to work around our problem: 1) Add a new column to our table that will hold the OID of a postgresql user. 2) Use the postgresql user name to map to a record in our table (the easy solution). I was really just asking, in the first instance, why the changes had taken place - I appreciate everyones thoughts and inputs for help on our problem. > On the other hand, it's possible that the new role management in 8.1, > which has brought much more elaborate privilege handling, could have > rendered your user handling unnecessary. Have you considered exploring > that? Roles are a great improvement to postgresql, but we also talking security issues here: Our module controls things like: 1) how long before a user must change their password (daily, weekly, monthly etc) 2) password rotation - for example a user cannot use the same password within the last three changes 3) Password semantics: length of password, dictionary word checks and so on... 4) Restricting a users rights until they have changed their password (they cannot use the system until they change the password set by the administrator) That should give you an insight into why we created such a module as those are just some of the things it does... Thanks again for the input. Regards, Donald Fraser
