How to understand the 'TEMPORARY' keyword in CREATE FUNCTION statement?

[ericpai]

Hi, we have tried to use the CREATE FUNCTON statement, but I'm confused about the existence of the TEMPORARY key word. In which situation we don't need to persist the UDF meta data? And if such one exists, under cluster mode, a node will loss the UDF meta data forever after restarting, but other nodes still have it. Thus the meta data is not consist.

[SteveYurongSu]

😂 Congratulations, you found a hidden feature (or a bad design) that didn't show up in the user documentation.

At first, I wanted to support user (or session) isolation UDF based on this feature: when a user disconnects or a session breaks down, their UDFs will be deregistered automatically. But in the end, I didn't implement the feature.

And if such one exists, under cluster mode, a node will lose the UDF metadata forever after restarting, but other nodes still have it. Thus the metadata is not consistent.

Your consideration is correct. You can create a PR to remove the TEMPORARY keyword and its logic, thanks!

[ericpai]

Thanks for your reply! I will handle this issue later~

[jixuan1989]

So, should we convert this question to an issue?

BTW, so what is the meaning of "TEMPORARY"...
Do we have two statements?

• create temporary function..., which will deregister the function after the session is closed.
• create function ..., while will persist the function no matter whether the session is closed.

[ericpai]

So, should we convert this question to an issue?

BTW, so what is the meaning of "TEMPORARY"...
Do we have two statements?

• create temporary function..., which will deregister the function after the session is closed.
• create function ..., while will persist the function no matter whether the session is closed.

Currently we have both CREATE FUNCTION and CREATE TEMPORARY FUNCTION statements, however, the CREATE TEMPORARY FUNCTION is not worked as other relational database(like you said).
Moreover, there're some drawbacks in the current UDF implementation:

1. The UDF registration must be done after the jar file had been deployed in udf root dir, which is hard to use in practice, because DB users may have no privileges to operation DB server file system directly without the help of DBAs.
2. In traditional database, UDF is defined by raw SQL statements, aka STORAGE PROCEDUGE. It's very lightweight to maintain, so a session level UDF is useful(they use CREATE TEMPORARY FUNCTION statement as well). But if we use jar files to implement and deploy an UDF, I think it's almost a regular one to use, so it's not necessary to leave the TEMPORARY keyword if we still use java code instead of SQL.
3. If we want to make it easier to use for users, not only for DBAs, I think we may extend the implementation to allow the user registering the function from remote resource files, i.e. download from http/https service with proper authorized information. Hence user can update their UDF smoothly without any jar file deployment works of DBA, especially in cluster environment with a lot of statistic UDFs, which are often iterated.

Sorry to talk too much which are not relavent with this thread. But removing TEMPORARY is necessary. I have created a jira issue in https://issues.apache.org/jira/browse/IOTDB-1716. This disscussion can be finished now.