Only require password when used #1356
Conversation
There was a problem hiding this comment.
I wonder about this use case. If you already define the user elsewhere, can't you simply use postgresql::server::database in the later places? What additional benefit is there in this defined type?
I see a tablespace relation, which is also in postgresql::server::database.
Then there is a GRANT. That isn't in postgresql::server::database, except for an owner. AFAIK that already implies all privileges so the only edge case is if you want that grant.
Am I missing anything?
|
Well the major use case from my end is "this is how we happen to use it, and it stopped working when d878d13#diff-09acae987abfb6f2de2796ebbbcee8911d8326cf762451972538f4f78984f35c was introduced". |
|
Oh, and right now, as a workaround, we're passing around |
There was a problem hiding this comment.
Mostly because it makes the code (even more) compile order dependent. If the inclusion happens in another order, it may fail because no password is provided. Then again, you could already have code where there are 2 different passwords specified and the real password used ends up being determined by the compile order.
Now looking deeper, I see postgresql::server::role can create a user without a password. So I think this is valid if you drop the fail() part. That should then also be reflected in the @param tags.
If the if in line 39 evaluates to false, the user has been created elsewhere, and we don't actually use (and thus need) password in `postgresql::server::db` class.
|
Done :) |
|
Did you forget to push? |
arjenz
force-pushed
the
allow_undef_password
branch
from
90e1522 to
4812333
Compare
Yes, yes I did :) |
There was a problem hiding this comment.
@david22swan this would have been nice to get in the release. However, I can't merge it because of a failed test.
If the if in line 39 evaluates to false, the user has been created
elsewhere, and we don't actually use (and thus need) password in
postgresql::server::dbclass.