Thanks david for pushing this forward. I have one concern about temporary objects and non-persistent catalog(e.g., GenericInMemoryCatalog). In SQL, temporary objects exist at the session level. They are only visible to the session in which they were created and are automatically dropped when that session logs off. So in that sense, all objects in non-persistent catalogs should be temporary.
My concern is: How does the non-persistent catalog work with temporary objects? *Best Regards,* *Zhenghua Gao* On Wed, Sep 4, 2019 at 10:20 PM Dawid Wysakowicz <dwysakow...@apache.org> wrote: > Hi all, > > As part of FLIP-30 > <https://cwiki.apache.org/confluence/display/FLINK/FLIP-30%3A+Unified+Catalog+APIs> > a Catalog API was introduced that enables storing table meta objects > permanently. At the same time the majority of current APIs create temporary > objects that cannot be serialized. We should clarify the creation of meta > objects (tables, views, functions) in a unified way. > > Another current problem in the API is that all the temporary objects are > stored in a special built-in catalog, which is not very intuitive for many > users, as they must be aware of that catalog to reference temporary objects. > > Lastly, different APIs have different ways of providing object paths: > > - String path…, > - String path, String pathContinued… > - String name > > We should choose one approach and unify it across all APIs. > > I suggest a FLIP to address the above issues. > > Looking forward to your opinions. > > FLIP link: > https://cwiki.apache.org/confluence/display/FLINK/FLIP-64%3A+Support+for+Temporary+Objects+in+Table+module >
