Thanks Eduard and Sung! I have addressed the comments. One key point to keep in mind is that catalog names in the spec refer to logical catalogs—i.e., the first part of a three-part identifier. These correspond to Spark's DataSourceV2 catalogs, Trino connectors, and similar constructs. This is a level of abstraction above physical catalogs, which are not referenced or used in the view spec. The reason is that table identifiers in the view definition/text itself refer to logical catalogs, not physical ones (since they interface directly with the engine and not a specific metastore).
Thanks, Walaa. On Wed, Apr 16, 2025 at 6:15 AM Sung Yun <sungwy...@gmail.com> wrote: > Thank you Walaa for the proposal. I think view portability is a very > important topic for us to continue discussing as it relies on many > assumptions within the data ecosystem for it to function like you've > highlighted well in the document. > > I've added a few comments around how this may impact the permission > questions the engines will be asking, and whether that is the desired > behavior. > > Sung > > On Wed, Apr 16, 2025 at 7:32 AM Eduard Tudenhöfner < > etudenhoef...@apache.org> wrote: > >> Thanks Walaa for tackling this problem. I've added a few comments to get >> a better understanding of how this will look like in the actual >> implementation. >> >> Eduard >> >> On Tue, Apr 15, 2025 at 7:09 PM Walaa Eldin Moustafa < >> wa.moust...@gmail.com> wrote: >> >>> Hi Everyone, >>> >>> Starting this thread to resume our discussion on how to reference table >>> identifiers from Iceberg metadata, a key aspect of the view specification, >>> particularly in relation to the MV (materialized view) extensions. >>> >>> I had the chance to speak offline with a few community members to better >>> understand how the current spec is being interpreted. Those conversations >>> served as inputs to a new proposal on how table identifier references could >>> be represented in metadata. >>> >>> You can find the proposal here [1]. I look forward to your feedback and >>> working together to move this forward so we can finalize the MV spec as >>> well. >>> >>> [1] >>> https://docs.google.com/document/d/1-I2v_OqBgJi_8HVaeH1u2jowghmXoB8XaJLzPBa_Hg8/edit?tab=t.0 >>> >>> Thanks, >>> Walaa. >>> >>
