Talat Uyarer created FLINK-40637:
------------------------------------
Summary: 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
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)
