Assuming the role on insuccient permissions error then try drop again

[slocke716]

This addresses #36

[phewitt]

Any chance this gets a look?

[slocke716]

I really hope so. This is my second attempt. The first one was not generic enough.

[slocke716]

Could someone please review this? At least decline it if you don't like it so I can try again. We are continually dealing with this issue.

[cyrilgdn]

@slocke716 Sorry for the delay and thanks for your work on that.

Unfortunately I'll probably decline it indeed as I already worked on a more "generic" fix for this problem and similar privileges problems on RDS on other resources.
I'm just trying to find a way to run tests on RDS like environment in order to test these fixes.

If it's too long, I'll probably create a PR without the tests in order to release it.

If you want to help on that, I may ask you to test it as you encounter this problem or even more to review the PR I'll create.

I keep this PR open until I'm sure that my fix is correct.

[cyrilgdn]

@slocke716 By the way I have a question on this reassign stuff, do you have use cases where you really want this reassign to be executed ?

I'm thinking to switch the default value of skip_reassign_owned to true as the REASSIGN OWNED command works only for the current database (so the one configured in the provider).

It makes no sense the way we use the provider in my company (we manage multiple databases, so the configured database in the provider settings is postgres and roles we create never have objects in this database).
But I was wondering if other users of the provider really needs reassign owned and drop owned to be executed when removing a role. (It's hard to take this kind of decision without knowing all possible use cases)

[slocke716]

@cyrilgdn Sorry for the delay. If I understand your question correctly, you'd like input and use-cases as to whether you should default skip reassigned to true.
As far as the default setting, its kind of irrelevant to us since we could just explicitly set it to false but we would in fact need that true. Our provider is configured specifically to the database in which we all our users are granted so we have an opposite use-case from you. We setup separate providers for separate databases and usually a separate database for us is actually an entirely different machine.
It is good to know that it would only work for 1 database though as we currently sometimes do create qa databases on the same server and that would be a head scratcher if that scenario came up.

[cyrilgdn]

I close this PR as #146 has been merged and released in v1.7.0 today and this should fix this issue.

Thanks for your work on this.