dybyte commented on PR #10779: URL: https://github.com/apache/seatunnel/pull/10779#issuecomment-5162374163
> Thanks @dybyte and @DanielLeens for pointing this out. > > I agree with the concern. With the current PostgreSQL `pgoutput` + Debezium 1.9 baseline, this PR should not assume that the original PostgreSQL DDL statement is available from the production WAL path. `pgoutput` exposes relation metadata updates rather than the raw DDL statement, so a real production schema-evolution implementation would need a different input path, most likely schema diffing from old/new table metadata, before this resolver can be wired into the runtime. > > Based on that, I have narrowed the PR to parser/resolver preparation only: > > * The PR title is now `Prepare schema evolution parsing`. > * `schema-changes.enabled` is not exposed for PostgreSQL CDC. > * `PostgresSourceConfigFactory` still sets `include.schema.changes=false`. > * `PostgresIncrementalSource` does not wire `PostgresSchemaChangeResolver` into the row deserializer. > * `SourceRecordUtils` still does not include PostgreSQL in the shared schema-change event key list. > * The Debezium JSON schema-change E2E remains disabled for the Debezium PostgreSQL 1.9 limitation. > > So there is currently no production path claiming to consume a DDL string from `pgoutput`. The added parser/resolver code is meant as groundwork for a later PR that supplies a real PostgreSQL schema-change input, for example by comparing relation/table metadata and then mapping that into SeaTunnel schema-change events. I will keep this PR scoped to that preparatory boundary and avoid advertising it as supported PostgreSQL CDC schema evolution. > > Also, the latest `Build` is green now. Thanks for clarifying that the current production path does not provide the original PostgreSQL DDL and that a metadata-diff-based approach would likely be required. However, I am still unclear about how the parser introduced in this PR would be used in that design. If schema changes are inferred by comparing the previous and current Debezium `Table` metadata, the implementation would appear to produce SeaTunnel schema-change events directly without parsing a DDL string. Could you clarify the concrete future runtime path that is expected to invoke `PostgresAlterTableParser`? Otherwise, I am concerned that this PR may add a substantial parser implementation that the planned production solution will not use. -- 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: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
