Support granting SELECT and UPDATE permission on sequences (MODULES-4158) #823
Conversation
Make the spec tests for postgresql::server::grant on sequences less sensitive to whitespace in the SQL.
Add additional acceptance tests for granting UPDATE permissions on sequences. (MODULES-4158)
Add support for granting SELECT and UPDATE permissions on sequences (MODULES-4158). This requires a significant change to the unless statement used to determine whether the permission has already been granted. The previous statement used the standard SQL information_schema tables, however these provide limited information on sequence permissions. In order to retrieve the current permission set with the necessary level of detail we must query the pg_class system catalog and parse out the permisions from there.
Remove unnecessary backslash escape in SQL regex for sequence grant unless query (it was causing ruby validation to fail).
| user = 'psql_grant_priv_tester' | ||
| password = 'psql_grant_role_pw' | ||
|
|
||
| pp_setup = <<-EOS.unindent |
There was a problem hiding this comment.
Variables should not be declared outside of tests. If it is needed by multiple tests then a let() should be used. Yes, our code does the same thing for db/owner/user/password and it's wrong and needs fixing :)
There was a problem hiding this comment.
This probably doesn't matter much.
There was a problem hiding this comment.
This was done for consistency with other spec tests (as you spotted).
Happy to change to something more sane if you want though - just let me know.
|
This looks great! Could you add the additional values to https://github.com/puppetlabs/puppetlabs-postgresql#privilege-1 as well? |
|
As for the docs, those additional values fall under " |
…ce-perms Support granting SELECT and UPDATE permission on sequences (MODULES-4158)
Add support for granting SELECT and UPDATE permissions on sequences (MODULES-4158).
This requires a significant change to the unless statement used to determine whether the permission has already been granted. The previous statement used the standard SQL information_schema tables, however these provide limited information on sequence permissions. In order to retrieve the current permission set with the necessary level of detail we must query the pg_class system catalog and parse out the permissions from there.
As part of this PR, I've added additional acceptance tests to verify both old and new functionality. All tests pass on my local system (using supplied Gemfile).