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