I still have an issue with representations not having explicit ways of incorporating the catalog name, I'm thinking about our potential future situation where we want to return a view for Fine Grained Access policies. In that case won't the Catalog need to craft a representation that matches the configuration of the engine? Doesn't this mean the client will have to tell the Catalog what its local name is?
On Thu, Oct 10, 2024 at 5:34 PM Daniel Weeks <dwe...@apache.org> wrote: > Hey Walaa, > > I recognize the issue you're calling out but disagree there is an implicit > assumption in the spec. The spec clearly says how identifiers including > catalogs and namespaces are represented/stored and how references need to > be resolved. The idea that a catalog may not match is an > environmental/infrastructure/configuration issue related to where they are > being referenced from. > > If we think this is sufficiently confusing to people, I would be open to > discussing an "unsupported configurations" callout, but I don't think this > blocks work and am somewhat skeptical that it's necessary. > > -Dan > > > > On Thu, Oct 10, 2024 at 2:47 PM Walaa Eldin Moustafa < > wa.moust...@gmail.com> wrote: > >> Hi Dan, >> >> I think there are a few questions that we should solve to decide the path >> forward: >> >> ** Does the current spec contain implicit assumptions?* >> I think the answer is yes. I think this is also what Ryan indicated here >> [1]. >> >> ** Do these implicit assumptions make it difficult to adopt the spec or >> evolve it in the correct way?* >> I think the answer is yes as well. MV design discussions became quite >> complicated because most contributors had a different understanding of the >> spec compared to what it encodes as implicit assumptions (see this thread >> for an example [2] -- there are a few more). This unaligned understanding >> could possibly lead to inaccurate designs and potentially result in >> unneeded further constraints or unneeded engineering complexity. >> >> ** What are the implicit assumptions (in an ambiguous way)?* >> I do not think the answer is clear to everyone, even at this point. There >> have been a few variations of those assumptions in this thread alone. I >> think we should converge on a clear set of assumptions for everyone's >> consumption. >> >> ** Should we add the assumptions explicitly to the spec?* >> I think we definitely should. Adoption or extension of the spec will be >> quite difficult if the assumptions are not clearly stated and are >> interpreted differently by different contributors. >> >> Would be great to hear the community's feedback on whether they agree >> with the answers to the above questions. >> >> [1] https://lists.apache.org/thread/s1hjnc163ny76smv2l0t2sxxn93s4595 >> [2] https://lists.apache.org/thread/0wzowd15328rnwvotzcoo4jrdyrzlx91 >> >> Thanks, >> Walaa. >> >
