Hi, +1 to strive for reaching consensus on the remaining topics. We are close to the truth. It will waste a lot of time if we resume the topic some time later.
+1 to “1-part/override” and I’m also fine with Timo’s “cat.db.fun” way to override a catalog function. I’m not sure about “system.system.fun”, it introduces a nonexistent cat & db? And we still need to do special treatment for the dedicated system.system cat & db? Best, Jark > 在 2019年9月18日，06:54，Timo Walther <twal...@apache.org> 写道： > > Hi everyone, > > @Xuefu: I would like to avoid adding too many things incrementally. Users > should be able to override all catalog objects consistently according to > FLIP-64 (Support for Temporary Objects in Table module). If functions are > treated completely different, we need more code and special cases. From an > implementation perspective, this topic only affects the lookup logic which is > rather low implementation effort which is why I would like to clarify the > remaining items. As you said, we have a slight consenus on overriding > built-in functions; we should also strive for reaching consensus on the > remaining topics. > > @Dawid: I like your idea as it ensures registering catalog objects consistent > and the overriding of built-in functions more explicit. > > Thanks, > Timo > > > On 17.09.19 11:59, kai wang wrote: >> hi, everyone >> I think this flip is very meaningful. it supports functions that can be >> shared by different catalogs and dbs, reducing the duplication of functions. >> >> Our group based on flink's sql parser module implements create function >> feature, stores the parsed function metadata and schema into mysql, and >> also customizes the catalog, customizes sql-client to support custom >> schemas and functions. Loaded, but the function is currently global, and is >> not subdivided according to catalog and db. >> >> In addition, I very much hope to participate in the development of this >> flip, I have been paying attention to the community, but found it is more >> difficult to join. >> thank you. >> >> Xuefu Z <usxu...@gmail.com> 于2019年9月17日周二 上午11:19写道： >> >>> 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!" >>> >
