Allow selecting multiple aggregate columns about diesel HOT 7 CLOSED

When supporting multiple aggregate columns we should consider that there could be queries that mix aggregate and non-aggregate fields. See for example the following query:

SELECT a.id, count(b::id) FROM a LEFT JOIN b ON a.id = b.a_id GROUP BY a.id;

from diesel.

@aturon @nikomatsakis Was thinking about this recently, and thought you might be interested as it would have been helped by the lattice rule, but could be aided by other additions to the type system as well. Basically we have an impl that looks like this for every size tuple:

impl<T, U> Expression for (T, U) where
    T: Expression + NonAggregate,
    U: Expression + NonAggregate,
{
    // ...
}

What we need is to write something along the lines of:

impl<T, U> Expression for (T, U) where
    T: Expression + !NonAggregate,
    U: Expression + !NonAggregate,
{
    // ...
}

With the lattice rule we could have added an Aggregate trait, and then had an impl for T: Expression + Aggregate + NonAggregate with a body that would force it to fail to compile if it was ever used. Ultimately though, what we really need here is either negative reasoning, or mutual exclusion.

The main goal (in case there's another solution that I'm missing) is to make sure that we do not have an impl for T: Aggregate, U: NonAggregate.

from diesel.

Also I know you had asked me to keep you in the loop when I find some concrete examples to point you guys at. Is there a preferred form of communication besides just pinging you on issues like this?

from diesel.

@sgrif this seems good. The hard part I guess might be finding these examples later -- I'll try to keep a log. For what it's worth, this would probably be addressed by the semi-proposal for negative reasoning I advanced in this comment, which itself is just a variant on rust-lang/rfcs#1148.

from diesel.

@sgrif Thanks for the heads up! In general issue comments like this are fine -- perhaps you could have a meta-issue with links to various examples as they come up, just so there's ultimately one place to track?

from diesel.

This problem could possibly be solved by using a PhantomData marker similar to these two examples: ebfull/pcap and hyperium/hyper.

from diesel.

Closed by #2251

from diesel.