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 >>
