[
https://issues.apache.org/jira/browse/CALCITE-1257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15305066#comment-15305066
]
Julian Hyde commented on CALCITE-1257:
--------------------------------------
This would be more concise than EXTENDS. The down-side is that the fields would
be of unknown type, inferred at run-time or perhaps based on the operators you
are using on them. It would be a lot like writing JavaScript.
Drill has a very non-standard treatment of {{SELECT *}}, where the actual
columns are only known when the data has been read. I wouldn't necessarily go
that far. On one of these tables, {{SELECT *}} would expand to {{SELECT _map}},
because {{_map}} is the only column we know about. But if you wrote {{SELECT
empno, deptno}} if you expand to {{SELECT _map['empno'] as empno,
_map['deptno'] as deptno}}.
> Late-binding schema
> -------------------
>
> Key: CALCITE-1257
> URL: https://issues.apache.org/jira/browse/CALCITE-1257
> Project: Calcite
> Issue Type: Bug
> Reporter: Julian Hyde
> Assignee: Julian Hyde
>
> Calcite should support late-binding schema, similar to what Drill does.
> Currently if we query a schema-less database such as MongoDB or Elasticsearch
> the best practice is to create a view that calls {{_MAP['fieldName']}} then
> casts the result to the desired data type. Creating that view is a
> significant effort. Certain tables should be flagged as having "late schema",
> and when validating queries against those tables, users should be able to
> reference any columns they like.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)