rward and agree on splitting it out.
>>
>> On Thu, Mar 26, 2020 at 4:04 PM Andrew Pilloud
>> 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 t
plitting it out.
>
> On Thu, Mar 26, 2020 at 4:04 PM Andrew Pilloud
> 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.
n Thu, Mar 26, 2020 at 4:04 PM Andrew Pilloud 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/38942fcb4775ed71f9b2ab8880ab68a423816
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
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