Validate `CREATE FUNCTION ... ENGINE` against existing user-defined
function storage before invoking driver `create_command`, so failed creates
and `IF NOT EXISTS` no-ops do not run driver side effects. Persist the
normalized `ATTACH FUNCTION` query before reloading the generated executable
UDF configuration.
Drain driver stdout and stderr concurrently in
`UserDefinedExecutableFunctionDriverInvoker` to avoid pipe-buffer deadlocks,
and keep stderr attached to non-zero and abnormal child exits.
Resolve relative `create_command` and `drop_command` paths relative to the
driver config file, fix the example XML for `xmllint`, and clean up the
dynamic executable UDF config repository during context shutdown.
Tests:
`ninja -C build programs/clickhouse`
`./tests/clickhouse-test -b ./build/programs/clickhouse 04241_executable_udf_driver`
`./tests/clickhouse-test -b ./build/programs/clickhouse 04242_executable_udf_driver_errors`
Refs: https://github.com/ClickHouse/ClickHouse/pull/105131
A driver describes how to create executable user-defined functions; calling
the surrounding element `<function>` was misleading - it suggested the file
described a single function. Rename to `<driver>` everywhere (example config,
parsing in the registry, the doc comment, both stateless tests).
Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>
Introduce "drivers" for executable user-defined functions. A driver is a
small adapter program declared in a server config under
`<user_defined_executable_function_drivers_config>` that knows how to take a
user-supplied code snippet and produce a runnable executable user-defined
function configuration.
New CREATE FUNCTION syntax:
CREATE [OR REPLACE] FUNCTION [IF NOT EXISTS] name [ON CLUSTER c]
ARGUMENTS (a UInt8, b String) RETURNS UInt64
ENGINE = DriverName(key1 = 'value1', key2 = 42)
AS '...code body...'
On CREATE FUNCTION, the corresponding `create_command` of the driver is
invoked: arguments are passed via `--name`, `--return`, `--args` and the
declared engine arguments; the body is sent on stdin; the driver writes the
resulting executable UDF configuration (XML or YAML) to stdout, which is
saved into the new `<dynamic_user_defined_executable_functions_path>` and
picked up by the existing executable UDF loader. The corresponding SQL is
persisted as `ATTACH FUNCTION ...` in `<user_defined>` and re-evaluated on
restart: if the dynamic configuration is still present, the driver is not
invoked; otherwise the driver is re-run to materialize it.
On DROP FUNCTION, the `drop_command` (if any) is invoked, then the dynamic
configuration file and per-function working directory are removed.
Includes a proof-of-concept driver `c_function_body`, which compiles a user
C body into a binary (inside Docker by default for build-time isolation) and
runs it inside Docker at query time with strict sandboxing (`--network=none`,
`--read-only`, dropped capabilities, no-new-privileges, unprivileged user,
resource limits) in `executable_pool` mode for batched per-row evaluation.
See https://github.com/ClickHouse/ClickHouse/issues/71172
Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>
Alexey Milovidov