Previously, redshift just directly used postgres' underlying
_postgres_container fixture. This means that you cannot simultaneously
use postgres AND redshift on different postgres database servers
(version/port would be common examples of things you might want to
customize).
Practically them being required to be the same container (before this PR)
makes it impossible to fully reproduce both postgres and redshift fixtures at
the same time when they operate on global resources like roles, or alter
container-wide settings like disabling foreign key checks for redshift.
Now, a separate _redshift_container and RedshiftConfig have been
added. By default they use the same values as the default postgres one;
which means that by default there will be no behavior change. A redshift
and postgres fixture, used together, will end up making use of the same
database server. However this change enables these configurations
to diverge for a project and use different config.
Additionally, postgres has had a lot more active development of its
fixture features. Redshift, using the postgres container, can make use
of all of this development, but had a completely unique implementation,
and so it did not.
Fixes https://github.com/schireson/pytest-mock-resources/issues/80
Previously, redshift just directly used postgres' underlying
_postgres_container
fixture. This means that you cannot simultaneously use postgres AND redshift on different postgres database servers (version/port would be common examples of things you might want to customize).Practically them being required to be the same container (before this PR) makes it impossible to fully reproduce both postgres and redshift fixtures at the same time when they operate on global resources like roles, or alter container-wide settings like disabling foreign key checks for redshift.
Now, a separate
_redshift_container
andRedshiftConfig
have been added. By default they use the same values as the default postgres one; which means that by default there will be no behavior change. A redshift and postgres fixture, used together, will end up making use of the same database server. However this change enables these configurations to diverge for a project and use different config.Additionally, postgres has had a lot more active development of its fixture features. Redshift, using the postgres container, can make use of all of this development, but had a completely unique implementation, and so it did not.