Implement more plugins

[nils-braun]

So far, basically all standard SELECT statements can be handled, because most of the RelNodes and RexNodes Apache Calcite will produce are already covered. However, there exist more of them and more advanced use cases might trigger them (leading to a NotImplementedError so far).

I would suggest to first find use cases of SQL, where those other classes are triggered, and then use them as a test case for the implementation.

Here is the list of java classes in the Apache Calcite project under rel/logical
and if they still need to be implemented:

• LogicalAggregate
• LogicalCalc -> a combination of project and filter, which is not in use as the corresponding optimization is not included (and also not needed)
• LogicalCorrelate
• LogicalExchange
• LogicalFilter
• LogicalIntersect
• LogicalJoin
• LogicalMatch
• LogicalMinus
• LogicalProject
• LogicalRepeatUnion
• LogicalSnapshot
• LogicalSortExchange -> not needed with the current optimizations
• LogicalSort
• LogicalTableFunctionScan
• LogicalTableModify -> not needed, as we do not want to have support table edits
• LogicalTableScan
• LogicalTableSpool -> no needed, as we do not want to have support table edits
• LogicalUnion
• LogicalValues
• LogicalWindow

[nils-braun]

Some information on how to tackle such a task:

1. Make sure to understand what the class does. This can be done by looking up the definition in the Apache Calcite source doe.
2. Build a SQL statement use case for it and debug it in the dask-sql command line tool, with debug turned on. This will give you the full generated algebra and where exactly you still need to implement something.
3. Add a new plugin in the rel/logical folder of dask_sql and also register it at the context.
4. For testing, maybe add a code.interact(local=locals()) instead of a real convert function and find out, which parameters the java instance has. Then implement the logic with Dask API calls. Have a look into other plugins.
5. Create some tests and do a PR :-)