Use this issue to track InQL RFC 033, proposed in PR #60 at docs/rfcs/033_adapter_requirements_coverage.md.
Area
- Specification (RFCs)
- Documentation
Summary
RFC 033 defines adapter requirements and coverage evidence so InQL can distinguish semantic plan validity from a backend adapter's ability to execute that plan.
Motivation
A query can be semantically valid while a specific adapter cannot execute all required operations. InQL needs structured coverage evidence for required capabilities, unsupported surfaces, partial support, and unknown states without letting DataFusion or any other first adapter own semantics.
Proposal sketch
- Define adapter requirements over semantic targets.
- Define coverage states such as supported, partial, unsupported, and unknown.
- Produce pre-execution diagnostics where adapter capability is known.
- Link requirements to semantic profiles and governed plan evidence.
- Keep backend inability in adapter capability/error handling rather than the core Substrait IR.
Alternatives considered
- Let backend runtime failures be the only signal.
- Maintain hardcoded support tables disconnected from plans.
- Treat Substrait support alone as the complete adapter coverage story.
Impact / compatibility
This is additive and evidence-focused. It should not invalidate existing plans, but future implementations can use the evidence to produce clearer diagnostics before execution.
Implementation notes (optional)
Review PR #60 for the draft. This work belongs at the adapter capability/evidence boundary, not as DataFusion-specific semantics.
Checklist
Use this issue to track InQL RFC 033, proposed in PR #60 at
docs/rfcs/033_adapter_requirements_coverage.md.Area
Summary
RFC 033 defines adapter requirements and coverage evidence so InQL can distinguish semantic plan validity from a backend adapter's ability to execute that plan.
Motivation
A query can be semantically valid while a specific adapter cannot execute all required operations. InQL needs structured coverage evidence for required capabilities, unsupported surfaces, partial support, and unknown states without letting DataFusion or any other first adapter own semantics.
Proposal sketch
Alternatives considered
Impact / compatibility
This is additive and evidence-focused. It should not invalidate existing plans, but future implementations can use the evidence to produce clearer diagnostics before execution.
Implementation notes (optional)
Review PR #60 for the draft. This work belongs at the adapter capability/evidence boundary, not as DataFusion-specific semantics.
Checklist