I'd love the other Drill guys to chime here on their thoughts. Your suggestion makes sense.
I'm not sure that Drill will have a problem since we do a final tree rewrite to avoid the name inconsistency issue. On Tue, Jul 21, 2015 at 12:23 PM, Julian Hyde <[email protected]> wrote: > Jacques, > > I can make the default instance (ProjectMergeRule.INSTANCE) have > force=true (currently it has force=false) and only remove a renaming > project if force=true. Then most people will get the benefit, but if > there is a problem you can switch Drill to using a custom instance. > > Also, this would be good reason to test Drill against a 1.4-SNAPSHOT > when it is posted. > > Julian > > > On Tue, Jul 21, 2015 at 11:18 AM, Jacques Nadeau <[email protected]> > wrote: > > I'm a little nervous about that for Drill. Despite the goal to do full > > testing to make sure we weren't accidentally using field names anywhere, > we > > haven't yet gotten very far. We know we're not supposed to depend on > > anything but ordinal but as a name based system, it is likely something > > depends on something there. > > > > On Tue, Jul 21, 2015 at 11:04 AM, Julian Hyde <[email protected]> wrote: > > > >> ProjectMergeRule currently refuses to reduce identity projects if the > >> fields have different names. > >> > >> For instance suppose you have a table Dept (deptno, name) and the > algebra > >> > >> 2: Project($1 as X, $0 as Y) > >> 1: Project($1, $0) > >> 0: Scan(Dept) > >> > >> Observe that if you combine projects #1 and #2 you end up with > >> > >> 3: Project($0 as X, $1 as Y) > >> 0: Scan(Dept) > >> > >> Although the new project (#3) is an identity, it renames the fields. > >> ProjectMergeRule will return the new project (#3), but it could return > >> Scan(Dept) (#0). > >> > >> Does anyone think they will break if I make it return #0? > >> > >> Julian > >> >
