Is your feature request related to a problem? Please describe.
Today redshift just piggybacks off postgres's container definition to start its container.
If we used the same existing container startup mechanisms for redshift as we do for postgres, but left the host/port/user/pass the same; then PMR will think it has already been started. And then we'll either want to prefix the database name with "postgres/redshift" or ensure they're both using the same PMR-specific table for record-keeping on tests.
With that said, we'd have the same default behavior as today, but with the ability to theoretically configure the settings to be different for redshift and produce a different container.
DanCardin
commented
2 years ago
Is your feature request related to a problem? Please describe. Today redshift just piggybacks off postgres's container definition to start its container.
This precludes us from making database-wide changes, like
SET session_replication_role = 'replica';which is a potential option for https://github.com/schireson/pytest-mock-resources/issues/62 and other specific kinds of tests.If we used the same existing container startup mechanisms for redshift as we do for postgres, but left the host/port/user/pass the same; then PMR will think it has already been started. And then we'll either want to prefix the database name with "postgres/redshift" or ensure they're both using the same PMR-specific table for record-keeping on tests.
With that said, we'd have the same default behavior as today, but with the ability to theoretically configure the settings to be different for redshift and produce a different container.