Som Frank forklarede, vil PostgreSQL afvise enhver forespørgsel, der ikke returnerer et reproducerbart sæt rækker.
Antag, at du har en forespørgsel som:
select a, b, agg(c)
from tbl
group by a
PostgreSQL vil afvise det, fordi b efterlades uspecificeret i group by udmelding. Kør det derimod i MySQL, og det vil blive accepteret. I sidstnævnte tilfælde skal du dog starte et par indsættelser, opdateringer og sletninger, og rækkefølgen af rækkerne på disksiderne ender anderledes.
Hvis hukommelsen tjener, er implementeringsdetaljerne således, at MySQL faktisk sorterer efter a, b og returnerer det første b i sættet. Men hvad angår SQL-standarden, er adfærden uspecificeret - og ganske vist gør PostgreSQL det ikke sorter altid, før du kører samlede funktioner.
Dette kan potentielt resultere i forskellige værdier af b i resultatsæt i PostgreSQL. Og dermed giver PostgreSQL en fejl, medmindre du er mere specifik:
select a, b, agg(c)
from tbl
group by a, b
Det Frank fremhævede er, at i PostgreSQL 9.1, hvis a er den primære nøgle, end du kan forlade b uspecificeret -- planlæggeren er blevet lært at ignorere efterfølgende grupper efter felter, når relevante primærnøgler indebærer en unik række.
Specielt til dit problem skal du specificere din gruppe ved, som du gør i øjeblikket, plus hvert felt, som du baserer dit aggregat på, dvs. "widgets"."id", "widgets"."user_id", [snip] men ikke ting som sum(amount) , som er de samlede funktionskald.
Som en sidebemærkning uden for emnet, er jeg ikke sikker på, hvordan din ORM/model fungerer, men den SQL, den genererer, er ikke optimal. Mange af de venstre ydre sammenføjninger ser ud til, at de burde være indre sammenføjninger. Dette vil resultere i, at planlæggeren kan vælge en passende joinordre, hvor det er relevant.