Skip to content

[Feature] Expose structured nested read types through the C ReadBuilder API #1385

Open

Description

@suxiaogang223

Search before asking

  • 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.

Anything else?

This is a C binding gap, not a request to reimplement core nested projection. See PR #1248, Rust ReadBuilder, and C projection.

Willingness to contribute

  • I'm willing to submit a PR!

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions