Tracking issue for parse module

[mbrobbel]

This is a tracking issue for a parse module in the Substrait crate.

Some requirements of Substrait can not be expressed via Protobuf definition or schema files. A parse module can provide types for the generated types, that when constructed are known to be checked. This enables producers and consumers to skip redundant checking of invariants described by the specification.

I want to propose incrementally building the parse module i.e. split up the intial work in #89 to help reviewers and to encourage collaboration.

Parser progress

Proto

• PlanVersion feat(parse): add proto::PlanVersion parser #165
  • Version feat(parse)!: add parse module and proto::Version parser #164
• Plan
  • Version feat(parse)!: add parse module and proto::Version parser #164
  • SimpleExtensionUri feat(parse)!: add proto::extensions::SimpleExtensionUri parser #169
  • SimpleExtensionDeclaration feat(parse): add proto::extensions::SimpleExtensionDeclaration parser #170
    • MappingType
      • ExtensionType
      • ExtensionTypeVariation
      • ExtensionFunction
  • PlanRel
  • AdvancedExtension
  • expected_type_urls
• PlanRel
  • RelType
    • Rel
      • ...
    • RelRoot
      • ...
• ExtendedExpression
  • Version feat(parse)!: add parse module and proto::Version parser #164
  • ...

Text

• SimpleExtensions
  • AggregateFunction
    • AggregateFunctionImplsItem
      • Arguments
        • ArgumentsItem feat(parse): add text::simple_extensions::ArgumentsItem parser #185
  • ...

Other tasks

• Add the parse module with traits to drive the parser feat(parse)!: add parse module and proto::Version parser #164
• Include core extensions in crate, so they can be added to a parse context
• Add a parser cli
• Add bindings to support using the parse module in other languages

[holicc]

Any plans to support parsing SQL directly?

[mbrobbel]

Any plans to support parsing SQL directly?

Absolutely. I think a logical next step would be to add builders for the parsed types, which could be used to build a SQL to substrait tool.

[holicc]

Any plans to support parsing SQL directly?

Absolutely. I think a logical next step would be to add builders for the parsed types, which could be used to build a SQL to substrait tool.

Cool! I'm interested in this. Anything I can do?

[mbrobbel]

Any plans to support parsing SQL directly?

Absolutely. I think a logical next step would be to add builders for the parsed types, which could be used to build a SQL to substrait tool.

Cool! I'm interested in this. Anything I can do?

If you want to contribute: this task would be a good one. Or else figuring out an ergonomic design for the builders.