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 <sniem...@apache.org> 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? >
