[
https://issues.apache.org/jira/browse/CALCITE-819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde resolved CALCITE-819.
---------------------------------
Resolution: Fixed
Fix Version/s: 1.5.0-incubating
Fixed in
http://git-wip-us.apache.org/repos/asf/incubator-calcite/commit/5a397063.
> 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
> Fix For: 1.5.0-incubating
>
>
> 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)
