I started a discussion about moving sqlparser into Apache Software
Foundation governance[1].
Please provide any comments you may have there
[1]: https://github.com/sqlparser-rs/sqlparser-rs/issues/1294
On Thu, Feb 29, 2024 at 5:02 PM Andy Grove wrote:
> I will put this proposal on hold for now
I will put this proposal on hold for now and restart the conversation later
this year once DataFusion is a top-level ASF project.
Thanks again for all the feedback.
Andy.
On Wed, Feb 28, 2024 at 9:58 AM Andy Grove wrote:
> Thanks for all the feedback so far.
>
> It does seem that the least con
Thanks for all the feedback so far.
It does seem that the least contentious way to do this would be to follow
Andrew's suggestion of having a separate
apache/[arrow-]datafusion-sqlparser repository as this will ensure that we
do not end up adding any DataFusion dependencies to the sqlparser projec
One potential way "moving sqlparser-rs into DataFusion" could look is that
code/repo is moved from the sqlparser-rs [1] organization to the apache
organization. For example
https://github.com/sqlparser-rs/sqlparser-rs
to
https://github.com/apache/datafusion-sqlparser
We could continue development
Maybe it would be valuable to more explicitly define "moving back into
DataFusion project".
I assumed it meant absorbing into the datafusion repo, but it occurs to me that
may not be the case. Then, how would sqlparser-rs be "moved"?
# --
# Aldrin
https://github.
There are cases where people need datafusion but not a SQL parser. For
example, people building a composable query engine for graph or other data
modality may not choose SQL as the DSL. Decoupling them seems to be a good
idea.
On Tue, Feb 27, 2024, 6:20 AM Mehmet Ozan Kabak wrote:
> In this case
In this case, maybe we can bring sqlparser-rs into the ASF umbrella following
the arrow-datafusion model?
Once DataFusion becomes a top-level project, we could move it to
datafusion-sqlparser-rs — it would be a quasi-independent project just like how
DataFusion is today w.r.t. Arrow. But it wou
Julian, thank you for your insight. I very much agree with it.
> I think the ASF is wrong on this. I think it needs to provide a home
> for medium-sized projects such as sqlparser-rs in an existing
> top-level project;
It could be said that DataFusion fits this model -- it isn't really an
"Arrow
I am torn on this.
One one hand, I am a big fan of components that are standalone - have
no more dependencies than necessary, and are self-evidently
standalone. So, I think that re-absorbing sqlparser-rs back into
DataFusion would not be a good step. It would reduce the perception
that it is stand
Sorry for the late reply,
I think sqlparser-rs users are quite a bit more varied than DataFusion and
there is not a large overlap between the contributors of the two projects.
I currently seem to be the one reviewing / merging most sqlparser-rs
reviews, and I would definitely love some more help.
<<< text/html; charset=utf-8: Unrecognized >>>
publicKey - octalene.dev@pm.me - 0x21969656.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
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.
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, And
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
14 matches
Mail list logo
