Както Франк обясни, PostgreSQL ще отхвърли всяка заявка, която не връща възпроизводим набор от редове.
Да предположим, че имате запитване като:
select a, b, agg(c)
from tbl
group by a
PostgreSQL ще го отхвърли, защото b е оставен неуточнен в group by изявление. Изпълнете това в MySQL, за разлика от това, и ще бъде прието. В последния случай обаче задействайте няколко вмъквания, актуализации и изтривания и редът на редовете на страниците на диска в крайна сметка е различен.
Ако паметта не ме лъже, подробностите за изпълнението са така, че MySQL действително ще сортира по a, b и ще върне първото b в набора. Но що се отнася до SQL стандарта, поведението е неуточнено -- и със сигурност PostgreSQL не винаги сортирайте, преди да стартирате агрегатни функции.
Потенциално това може да доведе до различни стойности на b в набор от резултати в PostgreSQL. И по този начин PostgreSQL дава грешка, освен ако не сте по-конкретни:
select a, b, agg(c)
from tbl
group by a, b
Това, което Франк подчерта е, че в PostgreSQL 9.1, ако a е първичният ключ, след което можете да оставите b неуточнено -- планиращият е научен да игнорира последваща група по полета, когато приложимите първични ключове предполагат уникален ред.
Конкретно за вашия проблем трябва да посочите групата си, както правите в момента, плюс всяко поле, върху което базирате агрегата си, т.е. "widgets"."id", "widgets"."user_id", [snip] но не и неща като sum(amount) , които са обобщените извиквания на функции.
Като странична бележка извън темата, не съм сигурен как работи вашият ORM/модел, но SQL, който генерира, не е оптимален. Много от тези леви външни съединения изглеждат така, сякаш трябва да са вътрешни съединения. Това ще позволи на планиращия да избере подходящ ред на присъединяване, където е приложимо.
