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 > >
