gianm commented on pull request #11911: URL: https://github.com/apache/druid/pull/11911#issuecomment-977953480
> This is a good call, but I think showing all potential errors won't help with debugging a 1000 line SQL query anyway since the query is too big. Ideally, we should be able to provide some context for each error where they are coming from in the query. I'm not sure how to do it though, maybe we can keep some context of the parent node while traversing the query plan tree. The best mechanism in Calcite for doing what you describe is post-parsing validation. It operates at an earlier stage: on the parse tree instead of the relational operator tree. Most of Calcite's builtin validations happen at that stage, and at that stage there is information available about line numbers, etc. Also it generally assumes that anything that makes it past the validator is a valid query, so I think that's why it has really "weird" errors from the planner when the planner can't plan something. I added some validations in another patch that operate on that parse tree (although they don't use line number info): https://github.com/apache/druid/blob/61bc7edd163b447fb7ec7a645f074f1e6320f36b/sql/src/main/java/org/apache/druid/sql/calcite/planner/DruidPlanner.java#L542-L577 Maybe we can use a similar technique for this stuff? i.e. whenever possible, look at the parse tree and identify certain patterns we cannot handle, before handing it off to the planner. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
