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

Reply via email to