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


##########
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:
   Apart from the above, the main point is that Benny's recommendation does not 
address the core issue this PR is trying to address, which is "sharing" both 
the default namespace and the default catalog names across engines. This will 
make partially specified identifiers portable across engines. Just "using the 
default namespace" does not guarantee portability.
   
   Let’s consider two engines, Engine A and Engine B and the following shared 
view SQL:
   
   ```sql
   SELECT * FROM y.z;
   ```
   
   Here, `y.z` is a partially specified identifier, with the catalog name 
omitted.
   
   Under Benny's version of the spec:
   
   * Engine A uses its default catalog (`x1`) and resolves the identifier as 
`x1.y.z`.
   * Engine B uses its default catalog (`x2`) and resolves the identifier as 
`x2.y.z`.
   * Both engines follow the suggested spec by "using the default catalog" to 
resolve the identifier, but they resolve it to different catalogs and tables 
because their default catalog names are not shared.



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