feat(udf): add initial support for JavaScript UDF

[wangrunji0408]

I hereby agree to the terms of the RisingWave Labs, Inc. Contributor License Agreement.

What's changed and what's your intention?

This PR adds an experimental support for JavaScript UDF.

# scalar function
dev=> create function add(a int, b int) returns int language javascript as $$
    return a + b;
$$;
CREATE_FUNCTION
dev=> select add(1, 2);
 add 
-----
   3
(1 row)

# table function
dev=> create function series(n int) returns table (x int) language javascript as $$
    for(let i = 0; i < n; i++) {
        yield i;
    }
$$;
CREATE_FUNCTION
dev=> select series(5);
 series 
--------
      0
      1
      2
      3
      4
(5 rows)

In this PR, we support scalar functions and table functions with all types except temporal types.

The JavaScript code is inlined in the create-function statement, stored in our catalog and run in an embedded QuickJS runtime rquickjs. I have verified that the runtime is sandboxed, users can do nothing but pure calculations. (QuickJS provides an std library including basic functions such as print and console.log in interpretation mode. But it's not available in the embedded mode.) You can review the arrow-udf-js crate to see how the runtime works.

In terms of performance, a simple test shows that JavaScript functions are ~60x slower than native functions.

Checklist

• I have written necessary rustdoc comments
• I have added necessary unit tests and integration tests
• I have added test labels as necessary. See details.
• I have added fuzzing tests or opened an issue to track them. (Optional, recommended for new SQL features Sqlsmith: Sql feature generation #7934).
• My PR contains breaking changes. (If it deprecates some features, please create a tracking issue to remove them in the future).
• All checks passed in ./risedev check (or alias, ./risedev c)
• My PR changes performance-critical code. (Please run macro/micro-benchmarks and show the results.)

• My PR contains critical fixes that are necessary to be merged into the latest release. (Please check out the details)

Documentation

• My PR needs documentation updates. (Please use the Release note section below to summarize the impact on users)

Release note

Adds an experimental support for JavaScript UDF.

See src/expr/udf/README-js.md for full documents.

[BugenZhao]

Sounds exciting!

QQ: why this is going to be merged into wasm-udf branch? Does the JS runtime have anything to do with WASM?

[wangrunji0408]

QQ: why this is going to be merged into wasm-udf branch? Does the JS runtime have anything to do with WASM?

Just don't want to resolve conflicts with that branch because I suppose the WASM PR will be merged soon. 🥵

[xzhseh]

Rest LGTM!

[yufansong]

Rest LGTM

[stdrc]

Rest LGTM

[fuyufjh]

Generally LGTM

[xxchan]

(Already discussed with Runji, also comment here)

The arrow conversion before calling js udf doesn't make total sense to me. Under the hood, arrow_udf_js::Runtime simply iterate over the rows of the RecordBatch, and then convert the row to js obj, and then eval with js func. And RisingWave chunk -> Arrow RecordBatch isn't zero-cost neither. So basically it just uses arrow's type system as the interface. Alternatively we can directly convert RisingWave's Row to js obj. The additional Arrow conversion has performance overheads and it also doesn't make implementation simpler. It's unlike external UDF and WASM UDF, where the Arrow data is passed to the guest for better performance, and end-users work with Arrow data directly. Arrow format is actually transparent to users for js udf here.

arrow_udf_js is like when you already have Arrow data, and how to do js udf with it. The rationale that this can be used by other ppl and benefit (and benefit from) the ecosystem is somewhat reasonable. Besides, I don't care performance that much and when we want to optimize it we can still save the arrow conversion without any breakage. So this is acceptable to me, and I prefer to ship this and let users try it.