udf: drop function should perform dependency check

[neverchanje]

Describe the bug

Currently, the DROP FUNCTION command does not check whether the function has dependencies with materialized views or sinks. This could cause undefined behaviors.

Error message/log

No response

To Reproduce

dev=> create table t (a int, b int);
CREATE_TABLE

dev=> CREATE FUNCTION add(a int, b int) RETURNS int LANGUAGE python AS $$
dev$> def add(x, y):
dev$>   yield a+b
dev$> $$;
CREATE_FUNCTION

dev=> create materialized view mv as select add(a, b) as c from t;                                                                                                                                                           CREATE_MATERIALIZED_VIEW

dev=> drop function add;
DROP_FUNCTION

dev=> insert into t values (1,1), (2,2), (3,3);
INSERT 0 3

dev=> select * from mv;
 c
---



(3 rows)

After the UDF add is dropped, all subsequent changes made to the MV fail to produce correct results.

Expected behavior

1. There should be a way to check dependencies of a UDF
2. drop function should perform dependency checks and fail with errors when dependencies exist.

How did you deploy RisingWave?

No response

The version of RisingWave

No response

Additional context

No response

[fuyufjh]

+1. Today I was asked by a user, too. The behavior is confusing to users. The "Expected behavior" mentioned in the PR is better to me.

[wangrunji0408]

The current behavior is that UDFs can be dropped without any dependency check. Materialized views which are using these UDFs will not be affected, because the UDF body has been embedded into the MVs. I agree that this is not intuitive to users and a dependency check should be added before dropping.

However, the example shown above is not related to this issue.

dev=> create table t (a int, b int);
CREATE_TABLE

dev=> CREATE FUNCTION add(a int, b int) RETURNS int LANGUAGE python AS $$
dev$> def add(x, y):
dev$>   yield a+b
dev$> $$;
CREATE_FUNCTION

dev=> create materialized view mv as select add(a, b) as c from t;                                                                                                                                                           CREATE_MATERIALIZED_VIEW

dev=> drop function add;
DROP_FUNCTION

dev=> insert into t values (1,1), (2,2), (3,3);
INSERT 0 3

dev=> select * from mv;
 c
---



(3 rows)

The reason of the empty output is that yield is mistakenly used in a scalar function and variable name a mismatches input x. Therefore you should see this error in the log and the output was set to NULL:

risingwave_stream::executor::actor: failed to evaluate expression identity="Project 1700000001" 
error=TypeError: 'generator' object cannot be interpreted as an integer suppressed_count=2

(Unfortunately, due to the nature of Python language, it's hard for us to ensure the source code is workable on creation.)

A correct reproducible example of this issue should be:

dev=> create table t (a int, b int);
CREATE_TABLE

dev=> CREATE FUNCTION add(a int, b int) RETURNS int LANGUAGE python AS $$
dev$> def add(a, b):
dev$>   return a+b
dev$> $$;
CREATE_FUNCTION

dev=> create materialized view mv as select add(a, b) as c from t;                                                                                                                                                           CREATE_MATERIALIZED_VIEW

dev=> drop function add;
DROP_FUNCTION

dev=> insert into t values (1,1), (2,2), (3,3);
INSERT 0 3

dev=> select * from mv;
 c 
---
 4
 2
 6
(3 rows)

Expected behavior like postgres:

postgres=# drop function add;
ERROR:  cannot drop function add(integer,integer) because other objects depend on it
DETAIL:  materialized view mv depends on function add(integer,integer)

[xxchan]

Materialized views which are using these UDFs will not be affected, because the UDF body has been embedded into the MVs.

BTW, similar things apply to logical VIEWs. The implementation just inlines them, so practically it's ok to drop them without affecting downstreams. But I implemented the dependency check (without much consideration though) #6160

[neverchanje]

Sorry for giving the incorrect example.
If the inlined python udf won't be deleted, I don't have a strong motivation on this issue anymore. 😄
A dependency check will still be nice-to-have, but not vital.

[github-actions]

This issue has been open for 60 days with no activity.

If you think it is still relevant today, and needs to be done in the near future, you can comment to update the status, or just manually remove the no-issue-activity label.

You can also confidently close this issue as not planned to keep our backlog clean.
Don't worry if you think the issue is still valuable to continue in the future.
It's searchable and can be reopened when it's time. 😄

[fuyufjh]

Requested by user today.