Ah.. Thanks... On Feb 19, 2017 09:40, "[email protected]" < [email protected]> wrote:
> Sure, you can join two tables together and then e.g. add a number from the > left table to a number from the right table. > > SELECT a.foo + b.bar FROM a, b > > That outputs a relation with a column whose origin is two separate columns > in two separate tables. Even without the join, the origin may be two > columns in one table. > > > On Feb 18, 2017, at 7:49 PM, Sarnath K <[email protected]> wrote: > > > > Just curious...How can a column have multiple origins? Join key type > > scenarios where they have the same value regardless of where they > originate > > from? > > > > On Feb 19, 2017 09:18, "[email protected]" < > > [email protected]> wrote: > > > >> You can often get the original of a column via RelMetadataQuery. > getColumnOrigin(), > >> but keep in mind columns can have multiple origins or no origin at all. > >> > >>> On Feb 18, 2017, at 5:47 PM, barry squire <[email protected]> wrote: > >>> > >>> Hi everyone, > >>> > >>> Calcite's SQL parsing, planning and execution using the enumerators > >> module > >>> looks like a pretty good fit for an application I want to develop. > >> However, > >>> I have one requirement that I'd really appreciate some guidance on. > >>> > >>> Given an SQL query, I'm looking for a way to trace the lineage of a row > >>> from source tables, through each operator and eventually to the > results. > >>> This is so I can produce something similar to pig illustrate ( > >>> http://research.yahoo.com/files/paper_5.pdf). > >>> > >>> I'm still very new to Calcite, but if I understand it correctly, I > think > >>> could modify the BlockStatement that is generated in each > >>> Enumerator.implement function to track lineage between input and output > >>> rows. This doesn't seem wise though as it would lead to a custom fork > >> that > >>> I'd need to maintain. > >>> > >>> Can anyone provide some insight into the best way to approach this > >> problem? > >>> > >>> Thanks > >> >
