Skip to content

isthmus: the read relations drop filter, best_effort_filter and projection in both directions #1204

Description

@nielspardon

ReadRel carries filter, best_effort_filter and projection (a MaskExpression), and AbstractReadRel exposes all three. SubstraitRelNodeConverter reads none of them: visit(NamedScan) (205), visit(LocalFiles) (211) and visit(VirtualTableScan) (808) each build their Calcite relation from the schema alone, and getFilter() / getBestEffortFilter() / getProjection() appear nowhere in the file. SubstraitRelVisitor never sets them on the way back, so the loss is silent in both directions.

A read carrying a mandatory filter therefore converts to a Calcite plan that reads every row, with no error — wrong results rather than a refusal. The projection mask is worse than dropped: AbstractReadRel.deriveRecordType applies it (MaskExpressionTypeProjector.project(projection, base)), so the POJO's record type is the masked schema while the emitted Calcite row type is the unmasked one, and every field index a parent relation computed against the read is off.

NamedScan(names=[t], schema=[a i64, b string], filter=<pred>, projection=<mask>)

converts as if it were

NamedScan(names=[t], schema=[a i64, b string])

Refusing an unsupported field would be safer than dropping it, the way visitOther and visit(Join) refuse what they cannot express.

Reproduced on main at 7310fc8. Distinct from #1160, which is about the emit mapping (Rel.getRemap()), not these three fields. Found while reviewing #1151.

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