Skip to content

adapter: gate materialized view key forwarding behind a dyncfg#37655

Draft
antiguru wants to merge 1 commit into
MaterializeInc:mainfrom
antiguru:bridge-cse_01QsjLpaYwbdVd6pzeS6X35G
Draft

adapter: gate materialized view key forwarding behind a dyncfg#37655
antiguru wants to merge 1 commit into
MaterializeInc:mainfrom
antiguru:bridge-cse_01QsjLpaYwbdVd6pzeS6X35G

Conversation

@antiguru

@antiguru antiguru commented Jul 14, 2026

Copy link
Copy Markdown
Member

A materialized view's persisted RelationDesc records the unique keys the optimizer inferred from its plan.
Downstream consumers (reduce elision, redundant join, join planning) trust these keys for correctness.
These keys are not stable: an optimizer change or a replacement materialized view can produce different real keys while dependents were planned against the old ones, yielding wrong results.

Adds the enable_materialized_view_keys dyncfg, default off.
When off, both the creation and rehydration paths drop the inferred keys before they reach the persisted schema, so no consumer can rely on them.
Nullability forwarding is unaffected.

Motivation

Prevents unsound reliance on unstable optimizer-inferred materialized view keys.

Checklist

  • This PR has adequate test coverage / QA involvement has been duly considered. (trigger-ci for additional test/nightly runs)
  • This PR has an associated up-to-date design doc, is a design doc (template), or is sufficiently small to not require a design.
  • If this PR evolves an existing $T ⇔ Proto$T mapping (possibly in a backwards-incompatible way), then it is tagged with a T-proto label.
  • If this PR will require changes to cloud orchestration or tests, there is a companion cloud PR to account for those changes that is tagged with the release-blocker label (example).
  • If this PR includes major user-facing behavior changes, I have pinged the relevant PM to schedule a changelog entry.

A materialized view's persisted RelationDesc records the unique keys the
optimizer inferred from its plan. Downstream consumers (reduce elision,
redundant join, join planning) trust these keys for correctness, but they
are not stable: an optimizer change or a replacement materialized view can
produce different real keys while dependents were planned against the old
ones, yielding wrong results.

Add the `enable_materialized_view_keys` dyncfg (default off). When off, both
the creation and rehydration paths drop the inferred keys before they reach
the persisted schema, so no consumer can rely on them. Nullability
forwarding is unaffected.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@antiguru
antiguru force-pushed the bridge-cse_01QsjLpaYwbdVd6pzeS6X35G branch from 4a84a17 to a2270e7 Compare July 14, 2026 21:21
@antiguru antiguru changed the title adapter: gate materialized view key forwarding behind a feature flag adapter: gate materialized view key forwarding behind a dyncfg Jul 14, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant