Class NestedPaths
A dotted name is ambiguous by construction: location.city is either a
qualified reference to a relation's column or a path into a nested one, and only the
headings can say which. Resolving it by its tail binds it to whichever side
happens to carry a column called city, which is how a predicate over the left
input came to be evaluated against the right — as a selection pushed into the wrong
relation, and at run time as a comparison of the right's value with itself, so the
join matched every pair and quietly became a cross product.
An open schema owns nothing here. Schema-on-read resolves every name, so its answer to "do you carry this path" is vacuously yes and carries no evidence. That is the part worth having in one place: it has been gotten wrong independently in the optimizer and in the executor, and in both the mistake was the same one — guarding the whole comparison on both sides being closed, rather than declining the open side's answer. Those are not the same thing, because what follows a declined comparison is a fall back to the bare tail, which an open schema also answers.
Note what this deliberately does not change: asking one open schema to
resolve a path is right, and inference depends on it. An open source really can carry
location.city, and it types as ANY. What is worthless is that same
answer used as evidence against another side.
- Since:
- 0.1
-
Nested Class Summary
Nested ClassesModifier and TypeClassDescriptionstatic enumWhich side of a join a nested path belongs to. -
Method Summary
Modifier and TypeMethodDescriptionstatic NestedPaths.OwnerReturns which input resolvesreferenceas a path into a nested column.
-
Method Details
-
ownerOf
Returns which input resolvesreferenceas a path into a nested column.- Parameters:
reference- the dotted reference, as writtenleft- the left input's heading; nevernullright- the right input's heading; nevernull- Returns:
- which input resolves
referenceas a path into a nested column
-