*_join(x, y, by=c()) should do a cross join

[crowding]

It makes sense that inner_join with no by or by=NULL will do natural join, but if I explicitly specify a join on no keys i.e. inner_join(x, y, by=c()) I think it should produce the Cartesian product.

[krlmlr]

To me, a separate verb looks like a cleaner solution, and by = c() should perhaps raise an error.

[crowding]

Perhaps for interactive or one-off analysis. But when I am using dplyr join inside a reusable function, mathematical consistency trumps "looks cleaner."

[krlmlr]

Which result do you expect for a left join of a nonempty data frame with an empty data frame with by = c()?

left_join(iris, mtcars[0,], by = c())

By definition we'd need to return all of iris plus the mtcars column filled with NULL-s. This means we can't simply forward this case to a (future) cross_join() function. I'm also not aware of any SQL DBMS that supports this corner case.

[crowding]

I agree with that test case. The SQL implementations I've checked with so
far did in fact produce that result from either LEFT JOIN or LEFT JOIN ON
1=1.

On Wed, Sep 21, 2016 at 12:25 PM, Kirill Müller notifications@github.com
wrote:

Which result do you expect for a left join of a nonempty data frame with
an empty data frame with by = c()?

left_join(iris, mtcars[0,], by = c())

By definition we'd need to return all of iris plus the mtcars column
filled with NULL-s. This means we can't simply forward this case to a
(future) cross_join() function. I'm also not aware of any SQL DBMS that
supports this corner case.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#2041 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABV1N6Sp9BLGcg7YYw1m6wayv6Y9FfJ1ks5qsYS1gaJpZM4JW7PB
.

[krlmlr]

Then it might be worthwhile indeed to support it in dplyr. Nice 1=1 trick!

[krlmlr]

We should clearly think of this test if/when we do #557. Currently this looks like a lot of effort for little gain especially on the C++ side.

[hadley]

Part of more general #2240