Uh oh!
There was an error while loading. Please reload this page.
[Enhancement](udf) Reject bitmap, hll, and quantile_state in udf create - #63849
Conversation
hello-stephen
commented
May 28, 2026
Thank you for your contribution to Apache Doris. Please clearly describe your PR:
|
linrrzqqq
commented
May 28, 2026
run buildall |
linrrzqqq
commented
May 28, 2026
/review |
There was a problem hiding this comment.
Review completed for PR 63849. I did not find a blocking correctness issue in the actual GitHub PR patch.
Critical checkpoint conclusions:
- Goal/test: The PR rejects bitmap, HLL, and quantile_state for Java/Python UDF/UDAF/UDTF create paths. The new FE unit test and Python regression suites cover direct and nested object-type cases.
- Scope/minimality: The implementation is small and localized to CreateFunctionCommand, with tests added for the new validation.
- Concurrency/lifecycle: No new concurrency or lifecycle-sensitive behavior is introduced.
- Config/compatibility/protocol: No new config, persisted format, or FE-BE protocol change is introduced.
- Parallel paths: Java and Python paths both call the new validation; RPC behavior is unchanged.
- Error handling: Validation raises AnalysisException and keeps failures at analysis time.
- Test coverage: Coverage exists for Java/Python scalar and aggregate FE paths plus Python UDF/UDAF/UDTF regression cases. I did not run tests in this review runner.
- Observability/transactions/data writes/memory: Not applicable to this PR.
- Performance: The recursive type validation is bounded by type nesting and not on a query hot path.
User focus: No additional user-provided review focus was specified.
hello-stephen
commented
May 28, 2026
TPC-H: Total hot run time: 31966 ms |
hello-stephen
commented
May 28, 2026
TPC-DS: Total hot run time: 171440 ms |
hello-stephen
commented
May 28, 2026
FE Regression Coverage ReportIncrement line coverage |
hello-stephen
commented
May 28, 2026
FE UT Coverage ReportIncrement line coverage |
PR approved by at least one committer and no changes requested. |
PR approved by anyone and no changes requested. |
Uh oh!
There was an error while loading. Please reload this page.
…te (apache#63849) Problem Summary: UDF creation currently allows `BITMAP`, `HLL`, and `QUANTILE_STATE` in function signatures, but these object types are not exposed to Java/Python UDF runtimes as first-class values. They are effectively bridged as opaque bytes, and marked unsupported in [doc](https://doris.apache.org/docs/dev/query-data/udf/python-user-defined-function#data-type-mapping)
…te (apache#63849) Problem Summary: UDF creation currently allows `BITMAP`, `HLL`, and `QUANTILE_STATE` in function signatures, but these object types are not exposed to Java/Python UDF runtimes as first-class values. They are effectively bridged as opaque bytes, and marked unsupported in [doc](https://doris.apache.org/docs/dev/query-data/udf/python-user-defined-function#data-type-mapping)
…te (apache#63849) Problem Summary: UDF creation currently allows `BITMAP`, `HLL`, and `QUANTILE_STATE` in function signatures, but these object types are not exposed to Java/Python UDF runtimes as first-class values. They are effectively bridged as opaque bytes, and marked unsupported in [doc](https://doris.apache.org/docs/dev/query-data/udf/python-user-defined-function#data-type-mapping)
Problem Summary:
UDF creation currently allows
BITMAP,HLL, andQUANTILE_STATEin function signatures, but these object types are not exposed to Java/Python UDF runtimes as first-class values. They are effectively bridged as opaque bytes, and marked unsupported in doc