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


##########
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:
   So, I was imagining that table resolution in the query engine would work 
like this:
   
   1. Assume SQL identifier is already fully qualified and so first segment is 
the catalog name.  Query engine would see if this catalog exists and can 
resolve the remaining segments into a table/view.
   2. Prepend the view's catalog and default-namespace (optional) to the SQL 
identifier.  Now, try to resolve with the query engine's registered catalogs.
   3. If default-catalog is set, prepend the default-catalog and 
default-namespace (optional) to the SQL identifier.  Again, try to resolve with 
query engine's registered catalogs.
   
   I don't think there is anything new with item 1 and 3 but item 2 is 
interesting because it allows two different engines to reference the same table 
using different catalog names.  This works only when the table and view are 
stored in the same catalog.
   



-- 
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