I agree that it simplifies shipping new SQL features in DataFusion since we can develop the changes in the parser concurrently with the changes in other DataFusion crates and then release them all together.
The name of the crate would not need to change, so downstream users should see no impact. We would need to decide if we want to keep a separate version number or bring it in line with DataFusion version numbers (I have no preference either way). On Sat, Feb 17, 2024 at 11:09 AM Mehmet Ozan Kabak <o...@synnada.ai> wrote: > Doing this will probably reduce the time-to-ship for DataFusion features > that need parsing support due to increased convenience, so I’m inclined to > see it in a positive light. > > What would be the impact of doing this on people who use only > sqlparser-rs, if any? > > > On Feb 17, 2024, at 7:16 PM, Andy Grove <andygrov...@gmail.com> wrote: > > > > The sqlparser-rs project [1] seems to have become the de-facto SQL parser > > for Rust, with almost 4 million downloads so far. This was originally > part > > of DataFusion very early on, and I moved it into a separate project > because > > it seemed useful for other projects. This was before DataFusion was known > > as a composable query engine, and with hindsight, I probably should have > > left it as part of the DataFusion project. > > > > Now that DataFusion has a reputation as a composable query engine, I > think > > it would make sense to move this code back into DataFusion, where it > would > > benefit from a larger community of maintainers. > > > > I would like to hear thoughts from the Apache Arrow / DataFusion > community. > > Does this seem like a good idea? > > > > Thanks, > > > > Andy. > > > > [1] https://github.com/sqlparser-rs/sqlparser-rs > >
