You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@paimon.apache.org by "thswlsqls (via GitHub)" <gi...@apache.org> on 2026/07/13 22:40:29 UTC

[PR] [cdc] Fix PostgreSQL time(n) with n<=3 incorrectly mapped to INT in PostgresRecordParser [paimon]

thswlsqls opened a new pull request, #8609:
URL: https://github.com/apache/paimon/pull/8609

   ### Purpose
   
   fix #8604
   
   - The int32 branch of `PostgresRecordParser.extractFieldType()` handled only `io.debezium.time.Date` and fell through to `INT()`, missing the sibling `io.debezium.time.Time` logical type (int32, millis-of-day) that Debezium emits for PostgreSQL `time(0..3)` in the default adaptive mode.
   - This disagreed with the JDBC bootstrap path (`PostgresTypeUtils` maps `time` to `TIME(scale)`), crashing the sync on the first record. Now maps `io.debezium.time.Time` to `TIME(3)`.
   - Symmetric with the int64 `Timestamp` fix from #8222; `time(4..6)` (`MicroTime`, int64) was already handled.
   
   ### Tests
   
   - Added `PostgresRecordParserTest#testTimeMillisFieldMapsToTime3` (int32 `Time` maps to `TIME(3)`) and `#testPlainInt32FieldMapsToInt` (negative: plain int32 stays `INT`).
   - `mvn -pl paimon-flink/paimon-flink-cdc -Pflink1 clean install` — `PostgresRecordParserTest` 5 tests passed (checkstyle/spotless/rat gates green).
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@paimon.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

Re: [PR] [cdc] Fix PostgreSQL time(n) mapping and widen TIME precision in schema evolution [paimon]

Posted by "JingsongLi (via GitHub)" <gi...@apache.org>.
JingsongLi commented on PR #8609:
URL: https://github.com/apache/paimon/pull/8609#issuecomment-5058815599

   +1


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@paimon.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

Re: [PR] [cdc] Fix PostgreSQL time(n) with n<=3 incorrectly mapped to INT in PostgresRecordParser [paimon]

Posted by "JingsongLi (via GitHub)" <gi...@apache.org>.
JingsongLi commented on PR #8609:
URL: https://github.com/apache/paimon/pull/8609#issuecomment-4975276074

   Debezium maps `Time` to `TIME(3)` without exception, but schema evolution lacks logic for TIME precision compatibility. The initial PostgreSQL `time(0..2)` is treated as `TIME(n)`, and a comparison with `TIME(3)` still returns an `EXCEPTION`. Local verification directly shows that `TIME(0) -> TIME(3)` results in an `EXCEPTION`; therefore, the “`n <= 3`” mentioned in the title only fixes the case where `n = 3`.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@paimon.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

Re: [PR] [cdc] Fix PostgreSQL time(n) mapping and widen TIME precision in schema evolution [paimon]

Posted by "JingsongLi (via GitHub)" <gi...@apache.org>.
JingsongLi merged PR #8609:
URL: https://github.com/apache/paimon/pull/8609


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@paimon.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

Re: [PR] [cdc] Fix PostgreSQL time(n) mapping and widen TIME precision in schema evolution [paimon]

Posted by "thswlsqls (via GitHub)" <gi...@apache.org>.
thswlsqls commented on PR #8609:
URL: https://github.com/apache/paimon/pull/8609#issuecomment-5044914730

   Thanks for the review. You're right — the parser can only emit `TIME(3)` (Debezium sends `io.debezium.time.Time` as int32 millis for every `time(0..3)`), while the JDBC schema path keeps `TIME(n)`, and `canConvert()` had no TIME widening (only TIMESTAMP), so `TIME(0) -> TIME(3)` still threw. Added TIME precision widening to `canConvert` mirroring the TIMESTAMP branch — `time(0..2)` now converge on `TIME(3)` — with a test, and reworded the title. Just pushed.
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@paimon.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org