Support role configuration parameters

[wilsonjackson]

Adds an optional, repeatable parameter block to the postgresql_role resource, which is used to define arbitary configuration parameters for the role. This is equivalent to using ALTER ROLE [role] SET [param] TO [value].

Example:

resource "postgresql_role" "test_role" {
  name = "audited_user"

  parameter {
    name  = "pgaudit.log"
    value = "all"
  }
}

This is more or less an alternate implementation to #211, and is in line with the suggestion in a comment on that PR.

Some implementation notes:

1. Some configuration parameters are already supported by dedicated arguments: search_path, statement_timeout, idle_in_transaction_timeout, and role. To prevent those existing arguments from conflicting with this one and causing perpetual diffs, those parameters cannot be set with a parameter block.

2. There are some peculiarities with value quoting:

   Most general configuration parameters, for example client_min_messages, can either be quoted string literals or bare tokens in the ALTER ROLE statement. At least one — search_path — cannot be quoted. Or rather, quoting will give you unexpected results. Others, for instance pgaudit.log, must be quoted, or the statement will produce an error.

   To accommodate all circumstances including ones I wasn't able to personally test, I opted to include an optional quote property in the parameter block that defaults to true, so quoting can be selectively disabled if required.

Closes #210

[ayoul3]

Hey @cyrilgdn, this MR could really help us handle pg_audit for roles, do you think we can have it in the next release ? 🙏, cheers

[gregarndt]

@cyrilgdn Looks like someone has a possible PR posted to resolve this gap. Is there something the community can do to help move this PR along?

[vmercierfr]

Hello,
We have been using the fork with success for a while to manage pg_audit configuration for PostgreSQL roles
@cyrilgdn is there any plan to move further with this PR?

[bhoriuchi]

This is a great addition, however I do not think it supplants #211 because it requires the role to be created in the same resource. If you are for example using cloudsql postgres IAM users you must use the google provider to create the user. If you are using that user for the vault database secrets backend you need to add the CREATEROLE permission to that iam user after its added.

Additionally for special permissions https://www.postgresql.org/docs/current/sql-createrole.html i have not seen a way to use "ALTER ROLE %s SET %s TO %s" to set them so they likely need to be special cased to use ALTER ROLE [role name] [special permission]. CREATEROLE is one of these special permissions

[jyriok]

@cyrilgdn
hello, do you planning to merge this PR into the next release?
This would be very useful to us!
thanks :)

[Anton-Shutik]

@jyriok Seems like that repo is weakly supported :( I have similar PR, but it's waiting for a long time as well

[igor-nikiforov]

@cyrilgdn just a friendly ping here