In order to address DBZ-4808, I'd like to introduce partition awareness to the DatabaseSchema class. This way, metrics could use the schema for sourcing the tables only of the partition that they represent. In turn, this requires parametrizing the DatabaseSchema class with P extends Partition.

Currently, the getColumnValue() and rowToArray() methods of the JdbcConnection class accept parameters of the type DatabaseSchema. This leads to the problem that if we want to parameterize DatabaseSchema, we also have to parameterize JdbcConnection, all its subclasses and all related classes which is a chain reaction that I'd like to avoid.

The dependency of the "connection" class on the "schema" class doesn't look implemented by design. It is rather a hack due to the following reasons:

1. The connection belongs to the infrastructure layer while the schema is part of the higher-level application layer. Lower-level abstractions should not depend on the higher-level ones.
2. This dependency is declared in the base JdbcConnection class but is actually used only in PostgresConnection.
3. Despite the dependency on DatabaseSchema, the PostgreSQL connection actually uses only the TypeRegistry that the schema contains. This is a violation of the Interface Segregation Principle.
4. The schema itself doesn't use the type registry, it only exposes it via its public API. This is a violation of the Single Responsibility Principle.

The most straightforward solution seems to be to pass the type registry to PostgresConnection as a constructor dependency.