PostgreSQL Where count condition

SELECT a.license_id, a.limit_call
     , count(b.license_id) AS overall_count
FROM   "License"  a
LEFT   JOIN "Log" b USING (license_id)
WHERE  a.license_id = 7 
GROUP  BY a.license_id  -- , a.limit_call  -- add in old versions
HAVING a.limit_call > count(b.license_id)

Sedan Postgres 9.1 täcker primärnyckeln alla kolumner i en tabell i GROUP BY klausul. I äldre versioner måste du lägga till a.limit_call till GROUP BY lista. Utgivningsinformationen för 9.1:

Tillåt icke-GROUP BY kolumner i frågemållistan när primärnyckeln är specificerad i GROUP BY klausul

Mer läsning:

• Varför kan jag inte utesluta beroende kolumner från `GROUP BY` när jag aggregerar med en nyckel?

Tillståndet du hade i WHERE satsen måste flyttas till HAVING klausul eftersom den refererar till resultatet av en aggregerad funktion (efter WHERE har tillämpats). Och du kan inte hänvisa till utdatakolumner (kolumnalias) i HAVING sats, där du bara kan referera till indatakolumner. Så du måste upprepa uttrycket. Manualen:

En utdatakolumns namn kan användas för att referera till kolumnens värde iORDER BY och GROUP BY satser, men inte i WHERE eller HAVING klausuler; där måste du skriva ut uttrycket istället.

Jag ändrade ordningen på tabellerna i FROM klausul och rensade upp syntaxen lite för att göra det mindre förvirrande. USING är bara en notationsbekvämlighet här.

Jag använde LEFT JOIN istället för JOIN , så du utesluter inte licenser utan några loggar alls.

Endast icke-nullvärden räknas av count() . Eftersom du vill räkna relaterade poster i tabellen "Log" det är säkrare och något billigare att använda count(b.license_id) . Den här kolumnen används i join, så vi behöver inte bry oss om kolumnen kan vara null eller inte.
count(*) är ännu kortare och något snabbare, ännu. Om du inte har något emot att få ett antal 1 för 0 rader i den vänstra tabellen, använd det.

Bortsett från:Jag skulle råda inte för att använda blandade skiftlägesidentifierare i Postgres om möjligt. Mycket felbenägen.