Hi Steven, Assumption 1 in "Portable SQL table identifiers" states:
*All engines resolve a fully specified SQL identifier x.y.z to the same storage table identifier b.c in the same catalog a.* I think this assumption encodes the 4th assumption you shared. Assuming "x.y.z" resolves to "b.c" in storage catalog "a" across all engines is true, the following is also true: 1- When resolving to the same storage table identifier, the same catalog name must be used -- This is encoded by the fact that SQL catalog part is common as "x". (this addresses the first part of the 4th assumption you shared). 2- The mapping from "x.y.z" to "b.c" in storage catalog "a" can be done by federation, but that is an implementation detail. As long as we maintain the constraint that "x.y.x" is resolved consistently across engines to the same storage table, implementing this by federation or something else is irrelevant. (this addresses the second part of the 4th assumption you shared). Further, the Assumption 1 above is more comprehensive since it prescribes how to go about all of the SQL catalog part, namespace and table name, not only the catalog part. Thanks, Walaa. On Tue, Oct 8, 2024 at 9:41 PM Steven Wu <stevenz...@gmail.com> wrote: > 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 >>>>> >>>>>
