As Frank explained, PostgreSQL will reject any query that does not return a playable rowset.
Suppose you have a query like:
select a, b, agg(c) from tbl group by a
PostgreSQL will reject it because b remains undefined in the group by statement. Run this in MySQL, on the contrary, and it will be accepted. In the latter case, however, run a few attachments, updates, and deletes, and the line order on the pages on the disk ends.
If the memory is served, implementation details are such that MySQL actually sorts by a, b and returns the first b in the set. But as far as the SQL standard is concerned, the behavior is unspecified - and, of course, PostgreSQL doesn’t always sort it before running aggregate functions.
This could potentially lead to different b values in the result set in PostgreSQL. So PostgreSQL gives an error if you are not more specific:
select a, b, agg(c) from tbl group by a, b
What Frank stands out is that in PostgreSQL 9.1, if a is the primary key, you can leave b unspecified - the scheduler has learned to ignore the next group by fields when the applicable primary keys imply a unique row.
For your problem, in particular, you need to indicate your group, as at the present time, plus all the fields on which you base your population, i.e. "widgets"."id", "widgets"."user_id", [snip] , but not such things as sum(amount) , which are the aggregate function calls.
As a side note, I'm not sure how your ORM / model works, but the SQL generator is not optimal. Many of those who left outer joins seem like they should be inner joins. This will result in the scheduler being able to select the appropriate connection order, if applicable.