Compare commits

..

No commits in common. "337a614a0ad9b6854837c91ec1b49f8d81fb18d9" and "1d42673776101fd35371b47fd6432e4fc1dc5993" have entirely different histories.

View File

@ -1,29 +1,4 @@
# PostgreSQL expiration date management functions
## Description
This project tries to find a way to allow users the management of the `VALID UNTIL` expiration clause by themself.
All without granting `super` permissions and having a histoc of changes on a _pseudo-audit_ table
## Instructions
### First deploy
Deploy `passchanger.sql` on the desired cluster/database.
It will:
* create a `dba` schema
* create a `dba` role
* create the `pwdhistory` table for audit purpouses
* Grant the minimum permissions for this new role so the whole thing works
* Create the 2 needed functions and grant permissions on them to `dba`
### Allowing users to use that functions
Take the file `grants_to_grant.sql` and modify the username _dodger_ so it match the username that should have the permissions.
Execute the grants on the cluster/database you have deployed `passchanger.sql`
### Changing password & extending expiration date
# postgresql_passchanger_function
Have a look at the comments