tshauck opened a new pull request, #9729: URL: https://github.com/apache/arrow-datafusion/pull/9729
## Which issue does this PR close? Closes #533 ## Rationale for this change Being able to control the underlying parser is useful to be able to add capabilities between the SQL and logical plan layer, which can propagate downstream in the plan. This approach seems to work nicely insofar as modifying how the SQL becomes a user-defined Statement. I.e. here I'm wrapping DF's `Statement` with my own, and creating it based on the underlying result from `parse_copy`. However, I'm unsure on the next steps. E.g. with this strategy of wrapping the statement, I can't then use DF's machinery to generate the `LogicalPlan`, like using `sql_statement_to_plan`. It's not too bad in the basic case, as it'd be easy to generate a user defined logical node from this enum (or fall back to `sql_statement_to_plan`), but in more complex cases there's probably a better way, e.g. maybe to make `Statement` a Trait with a visit method, or something along those lines? There's probably a better/simpler approach :). Going to open this in draft, and will come back later today/tomorrow to see what the basic strategy for constructing a LogicalPlan would look like and see if that's a reasonable first chunk. Open to feedback on any of it, thanks! ## What changes are included in this PR? Makes the parser on DFParser public and adds an example. ## Are these changes tested? Manually ran the example. Seems to perform as expected. Though not sure what the best path is next. ## Are there any user-facing changes? Not breaking, but `parser` is available on `DFParser`. -- 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]
