Re: Best practice for exhaustive planning
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.
Le mar. 22 mai 2018 à 19:01, Kenneth Knowles <firstname.lastname@example.org> a
> Bumping this, as it ended up in spam for some people.
> On Tue, May 15, 2018 at 9:26 AM Kenneth Knowles <klk@xxxxxxxxxx> 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
> > 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
> > more clever?
> > And if this question demonstrates that we are using Calcite entirely
> > wrong, let us know :-)
> > Kenn