> > > I > suggest that you move the password to a separate table (my_role_password) > with 2 columns: > > 1. my_role_id > 2. password. > > This way you can make the my_role table totally unalterable by the user, > yet they can change their own password. > > Actually, you should NOT be storing passwords in plain text, they should > be stored as a secure hash (better than MD5). >
I have no clue what you are trying to get at here...the core problem is with database defined roles - which are maintained in the system catalog - and the fact that marking a session read-only disallows updates to the system catalog... I do not see how adding a user table with role and password overcomes that problem since the user table would be read-only too - so how would they still be able to change their password if the cannot alter the table (data alter, not structure). David J. -- View this message in context: http://postgresql.1045698.n5.nabble.com/Creating-a-role-with-read-only-privileges-but-user-is-allowed-to-change-password-tp5803562p5803582.html Sent from the PostgreSQL - general mailing list archive at Nabble.com.
