wmoustafa commented on code in PR #11365:
URL: https://github.com/apache/iceberg/pull/11365#discussion_r1881085717


##########
format/view-spec.md:
##########
@@ -97,7 +97,10 @@ Summary is a string to string map of metadata about a view 
version. Common metad
 
 View definitions can be represented in multiple ways. Representations are 
documented ways to express a view definition.
 
-A view version can have more than one representation. All representations for 
a version must express the same underlying definition. Engines are free to 
choose the representation to use.
+A view version can have more than one representation. All representations for 
a version must express the same underlying definition. Engines are free to 
choose the representation to use. For the table identifiers in the view 
definitions to be interoperable across engines, the following must be true:
+* All engines must resolve a fully specified SQL identifier to the same table 
in the same catalog.

Review Comment:
   @RussellSpitzer I think recommending the catalog part to be omitted is not 
very practical. Additionally, I am not in favor of "recommending" in a spec, 
because it leaves the door open about what is really supported vs not.
   
   That said, these are actually not intended to be "recommendations" on how 
the views are expressed, but rather "expectations/assumptions" about the 
multi-engine environment. Once those expectations are met, users can safely use 
any of `catalog.db.table`, `db.table`, or `table` without worrying about cross 
engine inconsistency. This is the objective of the PR. More details in [this 
doc](https://docs.google.com/document/d/1e5orD_sBv0VlNNLZRgUtalVUllGuztnAGTtqo8J0UG8/edit?tab=t.0)
 (specifically up to -and including- the "Portable SQL table identifiers" 
section). 



-- 
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: issues-unsubscr...@iceberg.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@iceberg.apache.org
For additional commands, e-mail: issues-h...@iceberg.apache.org

Reply via email to