Xuanwo 3728d41f02 feat: carry Function initialization in the canonical model (#4253) ...

A Function instance is created once with an initialization row
(`create(initialization, context)` in the Function Format), but nothing
in the client model could say what that row holds or where its values
come from, so every source-built Function ran with an empty row and
users pushed configuration through `env=` strings instead (ENT-2516).

This adds initialization to the canonical wire model without changing a
Function's identity:

- `FunctionSignature.initialization` lists the fields of the row, in
order. It is omitted when empty, so existing signatures and
FunctionVersion hashes are unchanged.
- `FunctionApplication.initialization` carries a binding's values as
JSON. The service validates them against the Function's fields and
re-encodes them as Arrow, so this JSON is transport only and never
hashed; that is why floats are accepted here while column-input literals
keep the Slice 1 domain.
- `FunctionBinding.initialization` is the validated one-row Arrow IPC
stream (base64) that every instance of the binding is created with.
Values belong to the binding, so one Function version can back several
columns with different values.
- The binding-shape check that guards schema mutations accepts the new
field; without it a table holding an initialized binding refused further
declarations.

Rust and Python share new canonical goldens for an initialized
application and binding.

The authoring side (class `@udf`, initialization arguments, shipped
helper code) is the stacked PR on top of this one.

2026-09-23 23:31:49 +08:00

..

lancedb

feat: carry Function initialization in the canonical model (#4253)

2026-09-23 23:31:49 +08:00

tests

feat: carry Function initialization in the canonical model (#4253)

2026-09-23 23:31:49 +08:00

type_tests

fix(python): expose inline types to downstream checkers (#3817)

2026-08-07 17:31:42 +08:00