Jak Frank vysvětlil, PostgreSQL odmítne jakýkoli dotaz, který nevrací reprodukovatelnou sadu řádků.
Předpokládejme, že máte dotaz jako:
select a, b, agg(c)
from tbl
group by a
PostgreSQL to odmítne, protože b je ponecháno nezadané v group by tvrzení. Spusťte to naopak v MySQL a bude to přijato. V druhém případě však spusťte několik vložení, aktualizací a smazání a pořadí řádků na stránkách disku skončí jinak.
Pokud paměť slouží, detaily implementace jsou takové, že MySQL skutečně seřadí podle a, b a vrátí první b v sadě. Ale co se týče standardu SQL, chování je blíže nespecifikované – a PostgreSQL jistě ne vždy před spuštěním agregačních funkcí seřadit.
To může mít za následek různé hodnoty b ve výsledkové sadě v PostgreSQL. PostgreSQL tedy způsobí chybu, pokud nejste konkrétnější:
select a, b, agg(c)
from tbl
group by a, b
Frank zdůraznil, že v PostgreSQL 9.1 pokud a je primární klíč, pak můžete ponechat b nespecifikováno -- plánovač byl naučen ignorovat následné seskupení podle polí, když příslušné primární klíče znamenají jedinečný řádek.
Konkrétně pro váš problém musíte svou skupinu specifikovat tak, jak to nyní děláte, plus každé pole, na kterém zakládáte svůj souhrn, tj. "widgets"."id", "widgets"."user_id", [snip] ale ne věci jako sum(amount) , což jsou volání agregovaných funkcí.
Jako vedlejší poznámku mimo téma si nejsem jistý, jak váš ORM/model funguje, ale SQL, který generuje, není optimální. Mnoho z těchto levých vnějších spojů se zdá, jako by to měly být vnitřní spoje. To bude mít za následek, že plánovač bude moci vybrat vhodnou objednávku spojení tam, kde je to možné.