Walaa, it doesn't seem to me that the doc captured Russel's idea. there could be a new assumption 4. If the catalog name is part of the table identifier, it should be consistent across engines. catalog federation can achieve the normalization/standardization of the catalog names
On Tue, Oct 8, 2024 at 6:17 PM Walaa Eldin Moustafa <wa.moust...@gmail.com> wrote: > 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 >>>> >>>>
