You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is a common issue with migration to v2.1 and standard UDFs like ABS, ROUND, etc. The usual workaround is to quote the UDF name, i.e. DROP EXTERNAL FUNCTION "ABS", but it doesn't work for Dialect 1 databases.
Actually, the issue is not limited to migration only. Neither you can create an UDF that's expected to override the built-in function with the same name. And it's not about new built-in function names only, the issue is about any new non-reserved keyword introduced in the parser.
This limitation is caused by some UDF related tricks in our parser. But it can be easily improved to handle DDL properly.
Submitted by: @dyemanov
This is a common issue with migration to v2.1 and standard UDFs like ABS, ROUND, etc. The usual workaround is to quote the UDF name, i.e. DROP EXTERNAL FUNCTION "ABS", but it doesn't work for Dialect 1 databases.
Actually, the issue is not limited to migration only. Neither you can create an UDF that's expected to override the built-in function with the same name. And it's not about new built-in function names only, the issue is about any new non-reserved keyword introduced in the parser.
This limitation is caused by some UDF related tricks in our parser. But it can be easily improved to handle DDL properly.
Commits: 8dd79ad fdee80e
====== Test Details ======
See core_3963.fbt: one may NOT to create UDF with name <N> if PSQL function does exist with <N>, and vice versa.
The text was updated successfully, but these errors were encountered: