Thanks to Tmo and Dawid for sharing thoughts. It seems to me that there is a general consensus on having temp functions that have no namespaces and overwrite built-in functions. (As a side note for comparability, the current user defined functions are all temporary and having no namespaces.)
Nevertheless, I can also see the merit of having namespaced temp functions that can overwrite functions defined in a specific cat/db. However, this idea appears orthogonal to the former and can be added incrementally. How about we first implement non-namespaced temp functions now and leave the door open for namespaced ones for later releases as the requirement might become more crystal? This also helps shorten the debate and allow us to make some progress along this direction. As to Dawid's idea of having a dedicated cat/db to host the temporary temp functions that don't have namespaces, my only concern is the special treatment for a cat/db, which makes code less clean, as evident in treating the built-in catalog currently. Thanks, Xuefiu On Mon, Sep 16, 2019 at 5:07 PM Dawid Wysakowicz <wysakowicz.da...@gmail.com> wrote: > Hi, > Another idea to consider on top of Timo's suggestion. How about we have a > special namespace (catalog + database) for built-in objects? This catalog > would be invisible for users as Xuefu was suggesting. > > Then users could still override built-in functions, if they fully qualify > object with the built-in namespace, but by default the common logic of > current dB & cat would be used. > > CREATE TEMPORARY FUNCTION func ... > registers temporary function in current cat & dB > > CREATE TEMPORARY FUNCTION cat.db.func ... > registers temporary function in cat db > > CREATE TEMPORARY FUNCTION system.system.func ... > Overrides built-in function with temporary function > > The built-in/system namespace would not be writable for permanent objects. > WDYT? > > This way I think we can have benefits of both solutions. > > Best, > Dawid > > > On Tue, 17 Sep 2019, 07:24 Timo Walther, <twal...@apache.org> wrote: > > > Hi Bowen, > > > > I understand the potential benefit of overriding certain built-in > > functions. I'm open to such a feature if many people agree. However, it > > would be great to still support overriding catalog functions with > > temporary functions in order to prototype a query even though a > > catalog/database might not be available currently or should not be > > modified yet. How about we support both cases? > > > > CREATE TEMPORARY FUNCTION abs > > -> creates/overrides a built-in function and never consideres current > > catalog and database; inconsistent with other DDL but acceptable for > > functions I guess. > > CREATE TEMPORARY FUNCTION cat.db.fun > > -> creates/overrides a catalog function > > > > Regarding "Flink don't have any other built-in objects (tables, views) > > except functions", this might change in the near future. Take > > https://issues.apache.org/jira/browse/FLINK-13900 as an example. > > > > Thanks, > > Timo > > > > On 14.09.19 01:40, Bowen Li wrote: > > > Hi Fabian, > > > > > > Yes, I agree 1-part/no-override is the least favorable thus I didn't > > > include that as a voting option, and the discussion is mainly between > > > 1-part/override builtin and 3-part/not override builtin. > > > > > > Re > However, it means that temp functions are differently treated than > > > other db objects. > > > IMO, the treatment difference results from the fact that functions are > a > > > bit different from other objects - Flink don't have any other built-in > > > objects (tables, views) except functions. > > > > > > Cheers, > > > Bowen > > > > > > > > -- Xuefu Zhang "In Honey We Trust!"
