Please vote on this issue by adding a :thumbsup: reaction to the original issue to help the community and maintainers prioritize this request
Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
If you are interested in working on this issue or have submitted a pull request, please leave a comment
Tell us about the feature
It is important to acknowledge that user management in the Percona Operator for PostgreSQL does not really deliver its end of the bargain. Users are created, but you can't start using them right away, as they don't have permissions to use {{public}} schema. This breaks a lot of declarative flows.
Now users have to come up with workarounds, like creating an init script with a config map:
{noformat}apiVersion: v1
kind: ConfigMap
metadata:
name: init-sql
data:
init.sql: |
\c database
GRANT CREATE ON SCHEMA public TO "user";{noformat}
Community Note
Tell us about the feature
It is important to acknowledge that user management in the Percona Operator for PostgreSQL does not really deliver its end of the bargain. Users are created, but you can't start using them right away, as they don't have permissions to use {{public}} schema. This breaks a lot of declarative flows.
Now users have to come up with workarounds, like creating an init script with a config map:
{noformat}apiVersion: v1 kind: ConfigMap metadata: name: init-sql data: init.sql: | \c database GRANT CREATE ON SCHEMA public TO "user";{noformat}
CrunhcyData operator resolves this with this: [https://access.crunchydata.com/documentation/postgres-operator/latest/tutorials/basic-setup/user-management#automatically-creating-per-user-schemas|https://access.crunchydata.com/documentation/postgres-operator/latest/tutorials/basic-setup/user-management#automatically-creating-per-user-schemas|smart-link]
We should follow a similiar approach.
Link to JIRA