Just opened Comment access to the doc. Link here again for convenience [1].
[1] https://docs.google.com/document/d/1e5orD_sBv0VlNNLZRgUtalVUllGuztnAGTtqo8J0UG8/edit Thanks, Walaa. On Tue, Oct 8, 2024 at 10:42 AM Walaa Eldin Moustafa <wa.moust...@gmail.com> wrote: > Thanks Steven! I think this fits in the framework of "portable table > identifiers" in the doc. I have stated the assumptions that should be added > to the Iceberg spec in that case (in the doc they are more abstract/generic > than the version you shared). Would be great to provide your feedback on > the assumptions in the doc. > > Thanks, > Walaa. > > > On Tue, Oct 8, 2024 at 9:40 AM Steven Wu <stevenz...@gmail.com> wrote: > >> I like to follow up on Russel's suggestion of using a federated catalog >> for resolving the catalog name/alias problem. I think Russel's idea is that >> the federated catalog standardizes the catalog names (for referencing). >> That could solve the problem. >> >> There are two cases/ >> (1) single catalog: there is no need to include catalog name in the table >> identifier. >> (2) multiple catalogs (backends): the view and storage table should be >> defined in a federated catalog. the references to source tables should >> include the source catalog names, which are standardized by the federated >> catalog. >> >> Thanks, >> Steven >> >> >> On Mon, Oct 7, 2024 at 11:16 PM Walaa Eldin Moustafa < >> wa.moust...@gmail.com> wrote: >> >>> Hi Everyone, >>> >>> As part of our discussions on the Materialized View (MV) spec, the topic >>> of "SQL table identifiers" has been a constant source of complexity. After >>> several iterations, the community has agreed not to use SQL table >>> identifiers in the table-side representation of MVs. However, that still >>> does not preclude referencing SQL table identifiers in views since they are >>> integral to view definitions. Therefore, it’s crucial to properly design >>> this aspect of the spec in order to improve the view spec as well as >>> unblock the progress on the MV spec. >>> >>> I’ve outlined the current gaps in the view spec along with some proposed >>> ways to address them in this document [1]. It would be great to get your >>> feedback so we can simplify future discussions around views and >>> materialized views. >>> >>> Looking forward to hearing your thoughts. >>> >>> [1] >>> https://docs.google.com/document/d/1e5orD_sBv0VlNNLZRgUtalVUllGuztnAGTtqo8J0UG8/edit >>> >>> Thanks, >>> Walaa >>> >>>
