removing a PostgreSQL role.
Add manual overrides if this isn't the desired behavior, but it should
universally be the desired outcome except when a ROLE name is reused
across multiple databases in the same PostgreSQL cluster, in which case
the `skip_drop_role` is necessary for all but the last PostgreSQL
provider.
We just check these for syntax rather than exact value because the
underlying archive library is free to evolve its exact encoding over time
as long as the result is semantically equivalent, and we don't want these
tests to break when we build on different versions of Go.
The change in #10787 used flatmap.Expand to fix interpolation of nested
maps, but it broke interpolation of sets such that their elements were
not represented. For example, the expected string representation of a
splatted aws_network_interface.whatever.*.private_ips should be:
```
[{Variable (TypeList): [{Variable (TypeString): 10.41.17.25}]} {Variable (TypeList): [{Variable (TypeString): 10.41.22.236}]}]
```
But instead it became:
```
[{Variable (TypeList): [{Variable (TypeString): }]} {Variable (TypeList): [{Variable (TypeString): }]}]
```
This is because the expandArray function of expand.go treated arrays to
exclusively be lists, e.g. not sets. The old code used to match for
numeric keys, so it would work for sets, whereas expandArray just
assumed keys started at 0 and ascended incrementally. Remember that
sets' keys are numeric, but since they are hashes, they can be any
integer. The result of assuming that the keys start at 0 led to the
recursive call to flatmap.Expand not matching any keys of the set, and
returning nil, which is why the above example has nothing where the IP
addresses used to be.
So we bring back that matching behavior, but we move it to expandArray
instead. We've modified it to not reconstruct the data structures like
it used to when it was in the Interpolator, and to use the standard int
sorter rather than implementing a custom sorter since a custom one is no
longer necessary thanks to the use of flatmap.Expand.
Fixes#10908, and restores the viability of the workaround I posted in #8696.
Big thanks to @jszwedko for helping me with this fix. I was able to
diagnose the problem along, but couldn't fix it without his help.
A new create_timeout attribute was added that had some backwards
incompatibilities, and as per discussion in #10823, it was determined we
could make upgrading to 0.8.x easier by fixing them, without really
losing any functionality.
Because create_timeout is not something stored or transmitted to the
API, it's not something we need a ForceNew on. Also, because an update
wouldn't result in an API call, we can add a state migration to avoid a
false positive diff that requires people to plan and apply but doesn't
actually make an API call.
Sean Chittenden