This is basically the point of the Babel parser, to be as liberal as possible in what SQL is accepted and configurable where things necessarily conflict between different implementations.
Andrew, could you clarify what you're hoping to contribute to Babel? I think support for any dialect of SQL will generally be welcomed :) -- Michael Mior [email protected] Le jeu. 25 avr. 2019 à 23:39, Lai Zhou <[email protected]> a écrit : > > Good news. > I found Julian created a new issue about various sql parsing. > https://issues.apache.org/jira/browse/CALCITE-3022 > I think it may be helpful to support various sql parsing in a unified > manner. > Calcite did use the SqlConformance to enable various SQL compatibility > modes, > but it's not enough to solve all the problems. > Except sql parsing, different sql engines also have differences on > type inferring, > type checking and implicit casting. > > > > > > > > Andrew Pilloud <[email protected]> 于2019年4月26日周五 上午7:28写道： > > > I was intending to send an email about this, thanks for starting the > > discussion. I'm on the team at Google that is open sourcing ZetaSQL. > > It is a C++ SQL parser used internally for the BigQuery standard sql > > parser, among other things. > > > > We've open source the Java frontend and Rui currently working on a > > adapter between ZetaSQL and Calcite for Apache Beam, but we'd probably > > be interested in contributing it directly to Calcite Bable at some > > point. Any thoughts on that? > > > > Andrew > > > > On Thu, Apr 25, 2019 at 4:08 PM Kevin Risden <[email protected]> wrote: > > > > > > https://github.com/google/zetasql > > > > > > Saw this come by on twitter not too long ago and figured share here since > > > it definitely overlaps with Calcite. > > > > > > Kevin Risden > >
