Just to clarify the use case: I'm building SQL plugin to analyze Java heap
dumps.
https://github.com/vlsi/mat-calcite-plugin
select * from "java.lang.String" s produces a row for each String in the
heap dump.
Then might be a case like
select u.path from "java.net.URL" u;
That is java.net.URL has "path" field which is of java.lang.String.
Of course Java classes can produce recursive types, so Node { Node next; }
bothered me.
The relevant issue is https://issues.apache.org/jira/browse/CALCITE-207
I have asked once if RelDataTypeProxy is welcome in Calcite (
https://issues.apache.org/jira/browse/CALCITE-207?focusedCommentId=14035245&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14035245
), however it looks like I have to implement it and see what breaks.
The idea there was to use RelDataTypeProxy("Node") as a type for the "next"
field. That should avoid "stackoverflow" on cyclic dependencies in types.
I would love to know your opinion on that if you happen to have one.
It's great that you update executor to support nested structs.
PS. I've not had a chance to review it.
Vladimir
