[
https://issues.apache.org/jira/browse/CALCITE-529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14245662#comment-14245662
]
Julian Hyde commented on CALCITE-529:
-------------------------------------
Do we really need this change? It opens up a can of worms if "literals" might
not be immutable or serializable.
If you want to reference an arbitrary object you could (1) stash it, generate a
handle (say a unique string), then dereference that handle using a system
function, or (2) create a parameter (similar to a JDBC bind variable).
> Allow to pass java object via rexBuilder.makeLiteral()
> ------------------------------------------------------
>
> Key: CALCITE-529
> URL: https://issues.apache.org/jira/browse/CALCITE-529
> Project: Calcite
> Issue Type: Bug
> Affects Versions: 1.0.0-incubating
> Reporter: Vladimir Sitnikov
> Assignee: Julian Hyde
> Labels: newbie
>
> Motivation: Rex is simpler that linq4j.
> For instance,
> 1) Sometimes it is easier to create a {{ProjectRel}} rather than lower the
> expression to low-level linq4j
> 2) XXXToEnumerableRule are easier to accomplish via TableFunctionScan. This
> allows to express the call via Rex and skip linq4j completely.
> For example:
> https://github.com/vlsi/mat-calcite-plugin/blob/master/MatCalcitePlugin/src/com/github/vlsi/mat/optiq/rules/InstanceAccessByClassIdRule.java#L43
> The problem is to pass non-literal java object to enumerable/interpreter
> conventions.
> For enumerable the implementation can use stash. For interpreter it can use
> the value as is, etc.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
