You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[Feature] Expose structured nested read types through the C ReadBuilder API #1385
I searched in the issues and found nothing similar.
Searched issues and PRs for nested projection, with_read_type, C read type, and C projection. Core projection work exists, including #1248, but no directly matching C binding request was found as of November 12, 2026.
Motivation
The Rust ReadBuilder supports with_read_type(Vec<DataField>). Core nested projection, including Parquet leaf pruning through ROW/ARRAY/MAP containers, is already implemented.
At main f91fdb8ab034887547a5ee2f26c1979e30250558, the ordinary C ReadBuilder only exposes paimon_read_builder_with_projection, which takes column names. It cannot express an equivalent recursive read type carrying field IDs and the selected children of nested containers.
Apache Doris currently disables its Rust reader for nested-pruned projections. A structured binding would let embedding engines reuse the existing Rust read semantics rather than reconstruct a full root value solely to discard its children.
Solution
Expose the existing structured read-type capability through an additive C API. The input representation needs agreement: for example, reuse a versioned DataField JSON representation or introduce an owned read-type handle. This issue does not prescribe the final signature.
The contract needs to preserve field identity, selected nested shape, output ordering, and null/empty-container semantics. Projection must not become an unchecked mechanism for changing the table's logical schema. Define precedence with name projection and case sensitivity, validation errors, and ownership.
Relevant coverage includes nested ROW, ARRAY and MAP, missing evolved fields, mixed-case names, explicit field IDs, invalid requests, and independent nullability of containers and children. Non-Parquet formats should retain core's existing full-decoder/outer-projection behavior where appropriate.
Activity