Étienne BERSAC

Hi @kato-sho . I worked out this and Postgres 16 changed deeply how unprivileged user creator should run. Actually, CREATEROLE is considered flawed until Postgres 16. Can you review #593...

Hi @dani, thanks for reaching. I'm not fond of handling secrets in ldap2pg, especially in ldap2pg.yml. This will ends up in logs and GitHub. ldap2pg logs every statements full. However,...

Could you use envsubst to preprocess ldap2pg.yaml ?

> I could, but that wouldn't bring me a lot of advantage for my use case (as my ldap2pg.yml is templated and already able to fetch values directly from vault)....

ok, I'm gonna implement simple `post` queries. This will help for add some tests too. I suggest the following syntax: ``` yaml post: - description: blah... sql: | ... ```...

> I think something like this could work for me :-) While at it, could a similar "pre" hook be added to ? If the post ones could be used...

I have updates on the design. What about including post and pre in rules like this : ``` yaml rules: - description: ... run: ALTER ROLE .... - description: ......

> While this would be ultra flexible, it's also a bit harder to use. If I want to be sure my role has the expected password, I have to add...

Hi. I implemented `before_create` and `after_create`. However, I feel something wrong regarding `always`. Should this be simply a `run` statement ? ``` yaml - role: alice run: ALTER ROLE alice...

Hi @dani, i added before/after hook to role creation. I'm still not confident on the meaning of `always`. I don't want to add `password` field because it defeat the purpose...