Hi Timo, Re 1) I agree. I renamed the title to "Extend Core Table System with Pluggable Modules" and all internal references
Re 2) First, I'll rename the API to useModules(). The design doesn't forbid users to call useModules() multi times. Objects in modules are loaded on demand instead of eagerly, so there won't be inconsistency. Users have to be fully aware of the consequences of resetting modules as that might cause that some objects can not be referenced anymore or resolution order of some objects changes. Re 3) Yes, we'd leave that to users. Another approach can be to have a non-optional "Core" module for all objects that cannot be overrode like "CAST" and "AS" functions, and have an optional "ExtendedCore" module for other replaceable built-in objects. "Core" should be positioned at the 1st in module list all the time. I'm fine with either solution. Re 4) It may sound like a nice-to-have advanced feature for 1.10, but we can surely fully discuss it for the sake of feature completeness. Unlike other configs, the order of modules would matter in Flink, and it implies the LOAD/UNLOAD commands would not be equal in operation positions. IIUYC, LOAD MODULE 'x' would be interpreted as appending x to the end of module list, and UNLOAD MODULE 'x' would be interpreted as removing x from any position in the list? I'm thinking of the following list of commands: SHOW MODULES - list modules in order LOAD MODULE 'hive' [WITH ('prop'='myProp', ...)] - load and append the module to end of the module list UNLOAD MODULE 'hive' - remove the module from module list, and other modules remain the same relative positions USE MODULES 'x' 'y' 'z' (wondering can parser take "'x' 'y' 'z'"?), or USE MODULES 'x,y,z' - to reorder module list completely