Oh I think I actually remember seeing that email on the calcite list. :) I agree that it being an alternate parser implementation in calcite itself would be ideal, but also agree (sadly) that that'll probably be a very slow process.
Splitting it into its own library in beam seems ideal, the only problem I can see is that beam is using a vendored version of calcite. I think to be useful the library itself would need to use a "stock" version of calcite. I think I'd have some time to spend on this as well, if we can figure out a good way forward and agree on splitting it out. On Thu, Mar 26, 2020 at 4:04 PM Andrew Pilloud <[email protected]> wrote: > I think it makes sense for the ZetaSQL to Calcite translation layer to > live in Calcite itself, and did suggest it at one point on their dev list > (See: > https://lists.apache.org/thread.html/38942fcb4775ed71f9b2ab8880ab68a4238166ea5e904111ca184a12%40%3Cdev.calcite.apache.org%3E). > I don't think there is a quick way to get there, but we could split up the > interfaces within Beam so they are cleaner. > > It seems like a good next step would be to split up packages within Beam. > We could add a set of core SQL interfaces that only depend on Calcite and > then split our ZetaSQL translator into a piece that only depends on those > interfaces, Calcite, and ZetaSQL. > > Andrew > > On Thu, Mar 26, 2020 at 12:41 PM Steve Niemitz <[email protected]> > wrote: > >> The ZetaSQL to calcite translation layer that is bundled with beam seems >> generally useful in cases other than for beam. In fact, we're using >> (essentially a fork of) it internally outside of beam right now (and I've >> fixed a bunch of bugs in it). >> >> Has there ever been any thought about splitting into a separate library >> without any beam dependencies? >> >
