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


##########
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:
   I would assume the resolution of the identifiers to work something like this:
   
   0. Get list of available catalogs
   1. Set the table-name equal to the last element.
   2. Check if the second to last element exists.
    - If it does, set the namespace equal to it.
    - If it doesn't, use the default-namespace
   3. Check if the next element in reverse direction exists
    - if the element is equal to an available catalog, set catalog-name to it
    - if the element exists and is not an available catalog, prepend it to the 
namespace and continue with step 3.
    - if the element doesn't exist, use the default-catalog 
   4. Check if the resolved catalog, namespace, and table exist
   
   The important thing is that if the namespace or catalog are not present, the 
default-namespace and default-catalog from the view version are used. The 
resolution currently doesn't fallback to use the view catalog. 
   
   If we would now opt to use the view catalog instead of the default-catalog 
if the catalog is not present, the behavior would be different compared to the 
current view spec. This is what I mean with breaking change.



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