[
https://issues.apache.org/jira/browse/FLINK-40637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated FLINK-40637:
-----------------------------------
Labels: pull-request-available (was: )
> Catalog view expansion falls back to the session database for unresolved
> references
> -----------------------------------------------------------------------------------
>
> Key: FLINK-40637
> URL: https://issues.apache.org/jira/browse/FLINK-40637
> Project: Flink
> Issue Type: Bug
> Components: Table SQL / Planner
> Reporter: Talat Uyarer
> Priority: Major
> Labels: pull-request-available
>
> When the planner expands a catalog view, references in the view's expanded
> query that cannot be resolved against the view's own catalog/database are
> silently resolved
> against the reader's current session database instead of failing. The same
> view can
> therefore return data in one session and fail (or read a different table) in
> another.
> [FLIP-71|https://cwiki.apache.org/confluence/spaces/FLINK/pages/130027509/FLIP-71+E2E+View+support+in+FLINK+SQL]
> stores the expanded form "to remember query context such as current
> database", so for views written by Flink's own catalogs every reference is
> already fully qualified and the fallback is unobservable. External catalogs
> backing cross-engine
> view formats such as Apache Iceberg views store the original, portable SQL
> and return it from CatalogView#getExpandedQuery(), which makes the fallback
> reachable.
> How you can reproduce (I tested in Flink 2.3, any external catalog whose
> getExpandedQuery can contain an unqualified reference; observed with the
> Iceberg connector):
> 1. USE CATALOG c; USE db2;
> 2. CREATE TABLE t (id BIGINT); INSERT INTO t VALUES (7);
> 3. Create view c.db.v whose stored/expanded SQL is: SELECT id FROM t
> 4. SELECT * FROM c.db.v – from a session in db2: returns 7
> 5. USE db;
> SELECT * FROM c.db.v – fails: "Object 't' not found"
> Step 4 succeeds only because resolution fell back to the session database
> after
> missing in the view's database. the view's meaning depends on who reads it.
> Expected behaviour is view expansion should be hermetic — resolve references
> against the view's
> own catalog/database (per FLIP-71's stored-context model) and fail with a
> clear error
> if a reference cannot be resolved there, rather than consulting the reader's
> session.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
