Details
-
Bug
-
Resolution: Unresolved
-
Major
-
None
-
None
Description
Postgres always uses NanoTime implementation in adaptive mode for time fields because Column#length and Column#scale aren't assigned and used consistently for time fields.
The reason for this is, that `io.debezium.relational.Column#length` and `io.debezium.relational.Column#scale` are assigned and used in an inconsistent way for time fields by different connector implementations.
ValueConverters like the generic JDBCValueConverters use `io.debezium.relational.Column#length` to get the precision of time fields. That's correct for MySQL connector implementation, but Postgres seems to always have a value of 15 for length and the fractional part size / precision is stored in scale. This leads to the issue that Postgres time fields in adaptive mode are always encoded using `io.debezium.time.NanoTime` instead of working adaptively, like expected and suggested.
imho postgres is eventually behaving well, because it could make sense to have the precision in scale. but according to the javadoc in io.debezium.relational.Column interface,it should go to #length().
Other types like timestamp could also be affected, because JDBCValueConverters always use column.length() there too and probably value assignment is broken for these Column instances too.