XiaoHongbo-Hope commented on PR #10336: URL: https://github.com/apache/paimon/pull/10336#issuecomment-5986377187
> The extraction pushdown is useful, but I would prefer to express it through projection expressions rather than expose `variant_fields` as a public API. Currently, callers have to describe both the output projection and the native reader's extraction plan, and the result exposes positional struct children (`"0"`, `"1"`, ...). > > Could we follow the alias-to-SQL-expression pattern used by [Lance's scanner](https://lance-format.github.io/lance-python-doc/all-modules.html#lance.LanceDataset.scanner) and [LanceDB's select](https://lancedb.github.io/lancedb/python/python/#lancedb.query.AsyncQuery.select)? For example: > > ```python > builder.with_projection({ > "id": "id", > "x": "try_variant_get(payload, '$.x', 'float')", > "y": "try_variant_get(payload, '$.y', 'float')", > }) > ``` > > The existing `List[str]` form could retain its column-name semantics, while the mapping form would describe named projection expressions. The output would be `id, x, y`, with each extraction specifying its own path, type, and error behavior. `try_variant_get` matches the current default `fail_on_error=False`; `variant_get` would express strict behavior. > > Paimon Rust already has the expression-to-read-type rewrite in [#460](https://github.com/apache/paimon-rust/pull/460). We could extract/reuse that logic to collect the Variant extractions, generate the existing `read_type`, pass it through `with_read_type`, and project the internal struct children into the requested output columns. This also follows [Spark's Variant extraction pushdown model](https://spark.apache.org/docs/4.1.1/api/java/org/apache/spark/sql/connector/read/SupportsPushDownVariantExtractions.html): users write logical expressions, and the planner derives the reader request. > > To keep this PR focused, the first implementation could support only ordinary columns and float32 Variant extractions, explicitly rejecting other expressions for now. It should preserve SQL null/cast/error semantics and verify both the named output schema and the actual extraction read type. The Lance comparison here is about the public API shape; it does not assume equivalent field-level I/O pushdown for Lance JSON. Thanks, updated the PR to use named projection expressions. It follows #460’s read-type pushdown path, without reusing its DataFusion-specific optimizer. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
