[
https://issues.apache.org/jira/browse/CALCITE-819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14643782#comment-14643782
]
Julian Hyde commented on CALCITE-819:
-------------------------------------
Maybe the "contract" could be a special subclass of RelNode that only ever
appears at the root of a tree, and has few or no rules that might screw it up.
> Add a "contract" for the result of a relational expression
> ----------------------------------------------------------
>
> Key: CALCITE-819
> URL: https://issues.apache.org/jira/browse/CALCITE-819
> Project: Calcite
> Issue Type: Bug
> Reporter: Julian Hyde
> Assignee: Julian Hyde
>
> Add a "contract" for the result of a relational expression consisting of:
> * column names (maybe not unique),
> * possible multiple uses of the same column (without duplicating the column
> in the input relational expression),
> * convention,
> * column data types,
> * physical representation (e.g. as List or Object[]),
> * sort order.
> Currently that contract is expressed by a relational expression. But all of
> the aspects of the contract are at odds with best practices for relational
> expressions elsewhere in the tree. This is why we want to represent the
> contract not as a relational expression.
> See CALCITE-793 for an example of how a query does not ask for a sorted
> result, but because it is posed on a sorted table the planner assumes that
> the result has to be sorted. Maybe back out parts of 793's fix as part of
> fixing this issue.
> We would probably be able to obsolete RelCollations.PRESERVE.
> It is possible that the contract would bubble up as far as the Avatica
> signature.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
