Re: Best practice for exhaustive planning
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 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 :-)