For most queries, the only thing you should need to implement is a scan and the rest can usually be implemented by Calcite. It would be good if you have a specific example of a query that fails.
-- Michael Mior [email protected] Le mar. 22 mai 2018 à 19:01, Kenneth Knowles <[email protected]> a écrit : > Bumping this, as it ended up in spam for some people. > > Kenn > > On Tue, May 15, 2018 at 9:26 AM Kenneth Knowles <[email protected]> wrote: > > > Hi all, > > > > Beam SQL uses Calcite for parsing and (naive) planning. Currently it is > > pretty easy to write a SQL query that parses and causes a "could not > plan" > > dump when we ask the planner to convert things to the Beam calling > > convention. One current example is using UNNEST on a column to yield a > > LogicalCorrelate + Uncollect. > > > > There may obviously always be bits we don't support, but we'd like to > > ensure that the user encounters a careful error message rather than a > > planner dump. Is there a best practice for ensuring that we have covered > > all the cases? Is it just "everything name Logical*" or is there > something > > more clever? > > > > And if this question demonstrates that we are using Calcite entirely > > wrong, let us know :-) > > > > Kenn > > >
