Thanks Jerry for starting this discussion. Functions are indeed important to us. We hope that engines will support SQL functions in the future, but now, we cannot support a unified function definition.
## Comments > parameters Name to be `inputParams`? Should it just be Array<DataField>? > returnType Name to be `returnParams`? It can also just be Array<DataField>. > properties Name to be `options`. > type and definitions We can just have a `Map<String, FunctionDefinition> definitions ` field, type to definition. Types can be: 1. "sql" => SqlFunctionDefinition(String sql) 2. "flink" => FlinkFunctionDefinition(String className, FunctionLanguage language, List<ResourceUri> resources) 3. "lambda" => LambdaFunctionDefinition(String definition, FunctionLanguage language) ResourceUri should be similar to Flink. > catalog We don't need a catalog field in this class. ## Example You should have an example, for example, the same function is used across engines by Flink and Spark. Best, Jingsong On Sun, Apr 27, 2025 at 11:48 AM lining jing <jinglini...@gmail.com> wrote: > > Hi devs, > I would like to start a discussion about PIP-31: Introduce Function > > As Paimon has supported table and view， maybe we could support function， > and we could use it in： > 1. Unified column-level filtering and processing capabilities (ps: for > email information encryption and decryption) > 2. Parameterized view capabilities: similar to retrieving views, it > supports parameters > > Looking forward to your feedback, thanks! > [1] pip-31 > <https://cwiki.apache.org/confluence/display/PAIMON/PIP-31%3A+Introduce+Function> > > Best, Jerry
