[aptend]

What type of PR is this?

• API-change
• BUG
• Improvement
• Documentation
• Feature
• Test and CI
• Code Refactoring

Which issue(s) this PR fixes:

Related to #30785, #30786.
Backport of #30799 to 4.2-dev.

What this PR does / why we need it:

View-only SELECT can fail with error 20101 when an index JOIN rewrite loses the original scan's view authorization. CREATE OR REPLACE VIEW also changes the view's logical identity and leaves existing grants attached to the old object.

• Carry the original scan's complete OriginViews, DirectView, snapshot and binding context into synthetic index JOIN scans, using the authorization representation in 4.2-dev.
• Replace the physical view inside the existing transaction and catalog locks while preserving its logical ID and grants. Reject replacing a base table; keep actual DROP/CREATE on a new identity.
• Initialize the engine relation's effective logical ID before materializing its cached TableDef, matching the relevant prerequisite already present in main (feat(plan): add bounded read-only view schema requests #29633). Repeated replacements in the same transaction now retain the original identity through commit and rollback; hidden index tables retain their own identities.
• Add planner/compiler regressions and extend the existing tenant authorization case to cover nested DEFINER views, INVOKER/direct-table denial, retained grant options, failed replacement, repeated replacement with commit/rollback and DROP/CREATE isolation. The target branch lacks main's orphan-grant cleanup; the last oracle checks that the newly created view has no inherited grants.

Source: @TrentShen (MatrixOne Cloud production report).

Validation on 4.2-dev with Go 1.26.4 and locally built native dependencies:

• Before the metadata fix, the new engine regression observes cached logical ID 0 and the extended SQL regression fails on lost identity/access. Authenticated tenant probes reproduce error 20101 after two replacements and commit with privilege cache both ON and OFF; after the fix, both probes preserve logical identity and existing access, and rollback restores the prior definition and identity.
• Complete pkg/vm/engine/disttae, pkg/sql/compile and pkg/sql/plan suites pass. The new engine regression also passes with -race -tags matrixone_test -short -parallel=2. Existing engine integration controls TestAlterTableBasic and TestRelationExists pass.
• make build, changed-package go vet, and incremental golangci-lint v2.6.2 pass (0 lint issues).
• grant_view_non_sys.sql passes twice on the same instance (65/65 each), with account cleanup and global privilege-cache restoration checked after each run. Related alter_view.sql and replace_view.test pass (113/113 total).

[qodo-code-review]

Qodo reviews are paused for this user.

Troubleshooting steps vary by plan Learn more →

On a Teams plan?
Reviews resume once this user has a paid seat and their Git account is linked in Qodo.
Link Git account →

Using GitHub Enterprise Server, GitLab Self-Managed, or Bitbucket Data Center?
These require an Enterprise plan - Contact us
Contact us →

[XuPeng-SH]

Request changes: repeated CREATE OR REPLACE VIEW in one transaction still invalidates existing grants.

Reviewed head 553e7b3dc564b6de5043a62e822d5debe1d5e16f against 26d3a200cb13f4be3b5f64d489bac75d8dcc5814, including all seven changed files and the surrounding planner authorization, catalog identity, locking and rollback owners. The index JOIN authorization changes follow the source scan correctly and introduce no unnecessary execution path or grants storage.

Validation: verified exact-head CI passes for pkg/sql/compile and all eight pkg/sql/plan race shards, SCA (0 issues), and grant_view_non_sys.sql (55/55). Independent real CN/TN and authenticated MySQL tenant probes reproduce the identity/grant failure below with privilege cache both on and off; rollback controls pass. The compiler stub regression only captures the Create context and cannot detect the engine's stale cached TableDef.

A separate warm-plan/view-definition issue also reproduces on the clean base and is excluded from the blocking finding. The unrelated TN CI race is not the reason for this request-changes decision.

[XuPeng-SH]

[P2] Preserve identity across repeated replacements in the same transaction

This reads the cached TableDef as the identity authority, but txnDatabase.createWithID calls tbl.GetTableDef(ctx) before assigning tbl.logicalId (txn_database.go:495,509). The newly created relation therefore retains a cached TableDef with LogicalId=0. On a second replacement in the same transaction, this fallback substitutes the first replacement's new physical ID instead of retaining the original logical ID.

Reproduced on this head through real CN/TN and authenticated tenant MySQL connections: grant SELECT on a view, then BEGIN; CREATE OR REPLACE VIEW ...; CREATE OR REPLACE VIEW ...; COMMIT. A fresh view-only reader fails with error 20101, with privilege cache both on and off. The engine probe records logical IDs 16385 -> 16385 -> 16386; rollback controls retain the old definition and access.

Please initialize/synchronize logical identity in the engine metadata owner before exposing its TableDef, and add a real transaction regression covering repeated replacement and commit/rollback. A compiler-local identity cache or another fallback would duplicate the existing metadata responsibility.

[aptend]

Fixed in 551de35.

createWithID now resolves and initializes the effective logical ID before GetTableDef materializes its cache. The existing hidden-index exclusion and logical-ID index update behavior are preserved.

Added an engine regression that fails on the old cached identity, plus real tenant SQL coverage for repeated replacement and commit/rollback. Before the fix, authenticated readers fail with 20101 with privilege cache both ON and OFF; the same probes pass after the fix. The extended authorization BVT passes twice (65/65 each), including grant-option retention and fresh reader checks.

Validation: complete disttae/compile/plan suites, focused engine race test, existing ALTER/RelationExists engine integration controls, build, vet and incremental lint pass. Related view BVT: 113/113. Requested re-review through the GitHub review-request API.