stevenzwu commented on code in PR #11041: URL: https://github.com/apache/iceberg/pull/11041#discussion_r3031253085
########## format/view-spec.md: ########## @@ -82,9 +97,12 @@ 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 [storage table identifier](#storage-table-identifier) of the storage table | When `default-catalog` is `null` or not set, the catalog in which the view is stored must be used as the default catalog. +When `storage-table` is `null` or not set, the entity is a common view, otherwise it is a materialized view. The storage table must be in the same catalog as the materialized view. Review Comment: Practically, are there use cases where storage tables won't be in the same catalog as the view definition? If no, it will be great to keep this restriction. Conceptually, a single logical entity of MV consists of two parts: view and storage table. It is natural that both components in the same catalog. [The new relation endpoint](https://docs.google.com/document/d/1VW5hgaaajRWtp5KbOU3s83YyoyPi5WOSvHtoJ_yXzJs/edit?tab=t.0#heading=h.e6w7vgpr8t2f) also work well with this restriction so that catalog can return the MV in one round-trip. -- 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: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
