Page History

...

We will add a new member variable to FunctionCatalog as “Map<ObjectIdentifier, UserDefinedFunction>  tempFunctions“ to hold those temporary functions in a central place, and new APIs “registerTemporaryScalar/Table/AggregateFunction(ObjectIdentifier, UserDefinedFunction)”. 

These functions have to reside in an available catalog and database - their lifespans are tied to catalog and database. 

• Upon registration of such functions, we need to first confirm that the catalog and database exist
• Upon lookup, we also need to first confirm the assigned catalog and database exist. If so, return the function; otherwise, we drop all the temporary functions in either the assigned catalog or the database. Such lazy dropping approach is necessary because these temporary functions don’t live in their assigned catalogs, and they are not aware of when databases or catalogs are dropped. (FYI, we had a discussion of whether catalogs should support temporary functions within themselves in which case such unawareness problem won’t occur, but decided to not do so at the moment) 

Lifespan of temp functions are not tied to catalogs and databases. Users can create temp functions even though catalogs/dbs in their fully qualified names don't even exist.

Their DDLs are “CREATE/DROP TEMPORARY FUNCTION”.

"SHOW FUNCTIONS" - list names of (temp) system/built-in functions, temp and catalog functions in the current catalog and db

"SHOW ALL FUNCTIONS" - list names of (temp) system/built functions, and fully qualified names of temp and catalog functions in all catalog and db 

"SHOW ALL TEMPORARY FUNCTIONS" - list names of all fully qualified names of temp and catalog functions in all catalog and db 

"SHOW ALL TEMPORARY SYSTEM FUNCTIONS" - list names of all temp system functionsTheir DDLs are “CREATE/DROP TEMPORARY FUNCTION”.

Lifespan of both types of temporary functions will be within a session, and will destroyed upon session end.

...