[Feature][Connector-V2][PostgreSQL-CDC] Support schema evolution

Search before asking

I searched existing issues with keywords including Postgres CDC schema evolution, PostgreSQL CDC schema evolution, Postgres-CDC SupportSchemaEvolution, and Postgres CDC DDL.

I found some closed umbrella/design issues such as CDC DDL sync design, but did not find an open issue that specifically tracks PostgreSQL CDC source schema evolution implementation.

What would you like to be added?

PostgreSQL CDC source should support schema evolution, similar to MySQL CDC and Oracle CDC.

Currently, PostgresIncrementalSource only implements SupportParallelism:

public class PostgresIncrementalSource<T> extends IncrementalSource<T, JdbcSourceConfig>
        implements SupportParallelism {

In contrast, MySQL CDC and Oracle CDC implement SupportSchemaEvolution and set a SchemaChangeResolver in the Debezium deserialization schema builder.

PostgreSQL CDC currently builds SeaTunnelRowDebeziumDeserializeSchema without a schema change resolver:

return (DebeziumDeserializationSchema<T>)
        SeaTunnelRowDebeziumDeserializeSchema.builder()
                .setTables(catalogTables)
                .setServerTimeZone(ZoneId.of(zoneId))
                .setTableIdTableChangeMap(tableIdTableChangeMap)
                .build();

As a result, PostgreSQL CDC cannot convert PostgreSQL DDL records into SeaTunnel SchemaChangeEvents in the same way as MySQL/Oracle CDC.

Why is this needed?

PostgreSQL CDC is an important CDC source. In real CDC pipelines, users often need to synchronize both data changes and table schema changes.

Without PostgreSQL CDC schema evolution support:

1. PostgreSQL CDC pipelines cannot perform end-to-end DDL synchronization.
2. Downstream sinks that already support schema evolution cannot benefit from PostgreSQL source DDL events.
3. Multi-table PostgreSQL CDC jobs require more manual schema maintenance.
4. The CDC schema evolution capability is inconsistent across MySQL, Oracle, and PostgreSQL sources.

Suggested implementation direction

Contributors are very welcome to help implement this.

A possible implementation plan:

1. Add a PostgresSchemaChangeResolver, similar to MySqlSchemaChangeResolver and OracleSchemaChangeResolver.
2. Wire the resolver into PostgresIncrementalSource#createDebeziumDeserializationSchema.
3. Make PostgresIncrementalSource implement SupportSchemaEvolution.
4. Define supported schema change types, at least:
   • add column
   • drop column
   • rename column
   • modify/update column
5. Add parser and resolver tests for PostgreSQL DDL.
6. Add integration/e2e coverage if possible, such as PostgreSQL CDC -> JDBC/Paimon/Iceberg sink with schema changes enabled.
7. Update documentation for PostgreSQL CDC schema evolution support and limitations.

Open questions

1. Which PostgreSQL DDL variants should be supported in the first phase?
2. Should table rename and comment-related DDL be handled in the same PR or follow-up PRs?
3. How should unsupported PostgreSQL DDL be reported to users?
4. Which sink should be used for the first end-to-end test?

Compatibility

This can be introduced as an additive feature. Existing PostgreSQL CDC behavior should remain unchanged unless users enable schema evolution and the selected sink supports applying schema changes.