raminqaf opened a new pull request, #28510: URL: https://github.com/apache/flink/pull/28510
## What is the purpose of the change
`EXPLAIN` previously rejected materialized table DDL, so users had no way to
inspect the plan that populates a materialized table without actually running
it. This change adds `EXPLAIN` support for `CREATE MATERIALIZED TABLE ... AS`,
`CREATE OR ALTER MATERIALIZED TABLE ... AS` (both the alter-on-existing and the
in-place
table-to-materialized-table conversion path from FLINK-39847), and `ALTER
MATERIALIZED TABLE ... AS`. The produced plan is the sink that writes the
definition query into the materialized table, mirroring how CTAS/RTAS are
explained.
`EXPLAIN` stays side-effect-free: no table is created, altered, or
converted, and no refresh job is submitted.
Note on scope: building the sink for a brand-new managed materialized table
at `EXPLAIN` time is not covered, because a managed table's storage options
(e.g. `path`) are only assigned by the catalog at creation time. The alter and
conversion paths work because they reuse the existing table's already-resolved
connector
options. Resolving managed options at plan time without persisting is left
as a follow-up.
## Brief change log
- Parser: allow `CREATE`/`ALTER MATERIALIZED TABLE` statements after
`EXPLAIN`, and reject a non-`AS` `ALTER` under `EXPLAIN` with a clear message.
- Make the materialized table create/alter/convert operations translatable
as `ModifyOperation`, carrying the validated `AS` query as the sink input;
`ModifyOperationVisitor` gains the corresponding `visit` methods.
- Planner: convert the inner materialized table statement when explaining,
and translate these operations into the sink `RelNode` that writes into the
resulting table (reusing the existing table's resolved options for
alter/convert).
- Gateway: guard operation dispatch so directly-executed materialized
table statements still route to `MaterializedTableManager` rather than the
generic `ModifyOperation` translation path (the new `ModifyOperation` role only
enables `EXPLAIN`, it must not change execution).
## Verifying this change
This change added tests and can be verified as follows:
- Parser tests for `EXPLAIN` of `CREATE`/`CREATE OR ALTER`/`ALTER
MATERIALIZED TABLE`, including the rejection of a non-`AS` `ALTER`.
- Planner plan tests (`TableSinkTest`) asserting the AST / optimized
physical / optimized execution plans for the create and alter variants.
- Gateway integration tests asserting the full `EXPLAIN` plan end-to-end
(against golden resources) for `ALTER ... AS`, `CREATE OR ALTER` on an existing
materialized table, and the table-to-materialized-table conversion, plus
assertions that `EXPLAIN` leaves the catalog object unchanged.
- Existing materialized table create/alter/convert ITs continue to pass,
confirming direct execution dispatch is unchanged.
## Does this pull request potentially affect one of the following parts:
- Dependencies (does it add or upgrade a dependency): no
- The public API, i.e., is any changed class annotated with
`@Public(Evolving)`: no
- The serializers: no
- The runtime per-record code paths (performance sensitive): no
- Anything that affects deployment or recovery: JobManager (and its
components), Checkpointing, Kubernetes/Yarn, ZooKeeper: no
- The S3 file system connector: no
## Documentation
- Does this pull request introduce a new feature? yes
- If yes, how is the feature documented? not documented (a follow-up
should note `EXPLAIN` support on the materialized table / `EXPLAIN` statement
docs)
#### AI-tooling disclosure
Generated cleanups by Claude Opus 4.8
--
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]
