JanKaul commented on code in PR #11041: URL: https://github.com/apache/iceberg/pull/11041#discussion_r1868916881
########## format/view-spec.md: ########## @@ -82,9 +98,13 @@ Each version in `versions` is a struct with the following fields: | _required_ | `representations` | A list of [representations](#representations) for the view definition | | _optional_ | `default-catalog` | Catalog name to use when a reference in the SELECT does not contain a catalog | | _required_ | `default-namespace` | Namespace to use when a reference in the SELECT is a single identifier | +| _optional_ | `storage-table` | A [partial identifier](#partial-identifier) of the storage table | Review Comment: I think there are two parts to this issue: Resolving the namespace and resolving the catalog. I would always resolve the namespace of the storage table as I think this should provide the most consistency. Requiring the query engine to resolve a partial reference on every access seems more fragile to me. Another point is that the storage table identifier is set by the query engine which has the complete information about the identifier. Resolving the catalog is more complicated as the discussion about the "catalog alias" problem shows. It makes sense to use an optional "catalog_name" here. The question is what happens if the value is not set. We have these options: 1. Use the same catalog for the storage table as for the view 2. Use the `default-catalog` from the view version (if I understand you correctly Dan) I'm in favor of Option 1 because my understanding is that the `default-catalog` relates to the references in the view representation and not to the view itself. I find it natural that the storage table is in the same catalog as the view. -- 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
