Indeed, I am not sure what qualifies a function for being part of the "standard operators" table, it looks to me like many SQL dialects have different implementations for these functions as well.
This has bearing on how the validator resolves overloaded functions, which is something that came up in an issue I filed: https://issues.apache.org/jira/browse/CALCITE-6518 I asked a question about this on the dev mailing list recently too: https://lists.apache.org/thread/2qldr1vv4kjxyf41149jd6242npl9poz The corresponding PR to the issue above (still unmerged) solves 1/3 of this problem by adding a new function to SqlKind which says which kinds should be interpreted as OTHER_FUNCTION. If we take that PR you can add new kinds, but if you are defining a function you will have to add it's kind to the getFunctionKind method. As for which functions to add, I think whatever functions you need that aren't there yet. This is an endless quest. Mihai ________________________________ From: suibianwanwan33 <suibianwanwa...@foxmail.com> Sent: Thursday, August 15, 2024 7:33 AM To: dev <dev@calcite.apache.org> Subject: What are the design criteria for Calcite functions I found that Mysql's STR_TO_DATE & DATE_FORMAT functions are not supported in Calcite, I tried to understand and contribute this. But I'm not too familiar with this part. I've found that there are some functions that are defined as calcite default functions in StdOperator, some that have SqlKind, and some that are defined as OtherFunction. Of course, there are also a lot of functions that are not supported. I would like to know how we can distinguish these behaviors. For example, what kind of functions should we define as calcite default functions, I observed that calcite doesn't have a function like to_timestamp, is this missing in the calcite standard?. And what functions should we add to calcite? Also, I'm wondering if this contribution is meaningful to calcite. Thanks for all the replies Thanks, suibianwanwan
