[jira] [Commented] (CALCITE-819) Add a "contract" for the result of a relational expression

["Julian Hyde (JIRA)" <ji...@apache.org>]

    [ 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)