TAP-12456: 【Wynn】pg 自定义字段类型适配

[jarad0628]

Jira: TAP-12456

Repo: tapdata-connectors
Target branch: develop

AI coding summary:

TAP-12456 实现总结

实现与评审一致性

Codexcli 的实现与两轮评审结论高度一致：主战场在 postgres-core 的 physical WAL 解码链路，覆盖了 enum 标量与 enum 数组两类，目标端 MSSQL 无需改动。具体对应关系：

评审建议	实现状态
RelationCatalog join pg_type 加载 pg_enum 映射	✅ 已实现
PgTypeDecoder.decode() 按 OID 查映射输出标签字符串	✅ 已实现
decodeArray() 废弃 >10000 启发式、按定长 4 字节读 enum 元素	✅ 已实现
PhysicalWalLogMiner 共用类型解析	✅ 已实现
未知 OID 兜底 WARN 日志	⚠️ 未在变更摘要中明确提及，建议快速抽查
ALTER TYPE ... ADD VALUE 缓存刷新	⚠️ 列为 residual risk，未做 pg_enum 专用 WAL 监听
domain/composite 处理	🔵 按耿杰指示暂不纳入本期范围

文件变更清单

1. ColumnInfo.java — 增加 enum 标签映射字段
2. RelationCatalog.java — 列加载 SQL join pg_type/pg_enum，构建 OID→label 映射
3. HeapTupleDecoder.java — 将 enum 映射传递到解码链路
4. PgTypeDecoder.java — 标量 enum 按 4 字节 OID 转标签；enum 数组元素按定长 4 字节读取并转标签
5. PhysicalWalLogMiner.java — DDL 分支共用类型解析
6. PgTypeDecoderTest.java / RelationCatalogTest.java — 新增对应单元测试

测试结果

• mvn -pl connectors-common/postgres-core -Dtest=PgTypeDecoderTest,HeapTupleDecoderTest,RelationCatalogTest test ✅
• mvn -pl connectors-common/postgres-core -Dtest='io.tapdata.connector.postgres.cdc.physical.*Test' test ✅

残余风险

1. 无实时 PG physical slot 集成测试 — 未使用真实 WAL 字节流端到端验证，建议按耿杰方向补充类集成测试：建表（enum 标量+数组列）、开启 [WAL-DEBUG]、抓字节流对比解码结果
2. ALTER TYPE ... ADD VALUE 场景未验证 — 当前依赖 catalog invalidation 清缓存，但未专门监听 pg_enum WAL 变更，新增枚举值可能在缓存刷新前解析失败
3. 未知 OID 静默回退 — 未确认是否已加 WARN 日志，建议抽查 PgTypeDecoder 兜底分支

结论

实现正确覆盖了核心问题（PG enum/enum array 在 physical WAL 增量阶段的乱码），变更范围精准、测试通过。上述残余风险不影响主流程功能，但建议在合并前补充一条集成测试用例以降低回归风险。

Pre-submit AI review: APPROVED by reasonix

APPROVED

TAP-12456 Pre-submit 代码评审（综合结论）

结论

实现正确覆盖了 Jira 描述的核心问题（PG enum / enum[] 在 physical 增量阶段的乱码），变更范围精准（仅 postgres-core 的 physical 解码链路，目标端 mssql 未动，符合评审范围），全部 146 个单元测试通过（BUILD SUCCESS）。可以进入自动化测试。

代码走查验证（逐路径核对）

标量 enum（如 status、mode）：

• RelationCatalog.COLUMNS join pg_type，typtype='e' 时加载 pg_enum OID→label 映射 ✓
• HeapTupleDecoder 定长分支（attlen=4）→ PgTypeDecoder.decode() 顶部 enum 分支 OID→label ✓

enum 数组（如 drawMode、property）：

• COLUMNS 中 LEFT JOIN pg_type et ON t.typelem = et.oid，解析元素 enum OID ✓
• decodeArray() 废弃 >10000 启发式，元素按定长 4 字节读取后走标签映射 ✓

DDL 变更路径：

• 缓存命中：applyPgAttributeChange → columnInfo()（带 resolveEnumTypeOid）✓
• pending 路径：已切换至 applyPendingChangesWithTypeInfo ✓
• enumTypeCache 随 invalidate() 一并清空 ✓

非阻塞改进建议（不阻碍合入，建议后续跟进）

1. 旧 applyPendingChanges 已成死代码：生产调用点已全部切换，仅 RelationCatalogTest.java:162 还在测试过期路径，建议删除并迁移测试。
2. COLUMNS 使用 INNER JOIN pg_type：理论上不会漏行，但一旦意外发生将导致所有后续列静默错位。建议改 LEFT JOIN 防御性更好。
3. 未知 OID 仍静默 UTF-8 回退：评审建议的 WARN 日志未落地（PgTypeDecoder.java:157）。enum 路径已不再触发，但其它自定义类型仍会静默产错，建议至少补一条 WARN。
4. 空数组（ndim=0）回退乱码：既有行为、非本次回归，但 drawMode/property 可能为空数组，验收时建议覆盖。
5. 无实时 WAL 集成测试：建议按耿杰方向补类集成测试（建表 + [WAL-DEBUG] 抓字节流对比），尤其覆盖 ALTER TYPE ... ADD VALUE 后新标签解析。

成员一致性

仅 Reasonix 一位成员参与本轮 pre-submit 评审，结论为 APPROVED，无分歧。

Automated test stage: not_required

No automated test was explicitly requested in the review comment.

Automated test required: no