Support reframe()

[mgirlich]

Not quite sure how to handle this.

• mutate() doesn't have the constraint on the number of rows, e.g. when using the SQL function unnest() it can increase/decrease the number of rows
• for the SQL translation it is necessary to know whether a verb is like mutate() or summarise() to decide whether to use a window function or not
• or should it simply throw an unsupported error?

[DavisVaughan]

One of the reasons for putting reframe() in a separate function from summarise() was that dbplyr could just say "we don't support reframe() because that isn't something most data bases can do"

That could be the default behavior, with some restrictions lifted if a data base does have those capabilities?

[mgirlich]

Actually, SELECT itself doesn't really care about how many rows are returned. I think there are 2 situations:

1. an aggregation function is used: every expression in SELECT must create 1 row per group
2. no aggregation function: do whatever you want. One example is UNNEST() or GENERATE_SERIES() which would be the right fit for reframe(). And these functions are now very common.

With the recent dplyr version SQL now feels very limited and not expressive... In particular, I love the new safety for joins with unmatched and multiple.

[mgirlich]

Decided to simply not support reframe() for now. At least this gives a more informative error. The alternative would be to define reframe the same as summarise.
Closed by 0b2840a