Hi Paul,
Regarding your point "We can also handle a map projection: `a.b` which
matches:
* A (possibly repeated) map
* A (possibly repeated) DICT with VARCHAR keys
* A UNION (because a union might contain a possibly-repeated map)
* A LIST (because the list can contain a union which might contain
HI Bohdan,
Thanks much for the explanations. First I'll explain how I'll solve the
projection problem given your explanation. Then I'll point out three potential
ambiguities.
We have a bit of code which parses the projection list, then checks if a column
from a reader is consistent with
Hi Paul,
the DICT projection acts as a placeholder now, the real implementation is
to be added when we completely switch to EVF. (Actually, at first I used
map projection but added dict projection to separate this two.) These two
projections are currently the same - it can be removed now and
Hi Bohdan,
Thanks for your explanation. My question comes from a little project I'm
working on to handle projection in EVF. Queries go through two major steps:
planing and execution. At the planning stage we use SQL syntax for the project
list. For example:
explain plan for SELECT a,
Hi Paul,
`SELECT myMap.x ...` and `SELECT myMap['x'] ...` is treated the same in
Drill - schema path parser recognizes it as `myMap.x` in both cases.
The same is true for DICT - both `myDict['key1']` and myDict.key1 allows
Python-like syntax for projecting DICT values, but in schema path it is
Hi All,
What did we decide to do about projecting DICT values? Drill allows us to
project specific MAP members:
SELECT myMap.x ...
And, Drill allows projecting array members:
SELECT myArray[3] ...
I thought there was discussion of allowing Python-like syntax for projecting
DICT values:
