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)
Postgres 9.1以降、主キーはGROUP BYのテーブルのすべての列をカバーします 句。古いバージョンでは、a.limit_callを追加する必要があります GROUP BYへ リスト。 9.1のリリースノート：
GROUP BY以外を許可するGROUP BYで主キーが指定されている場合のクエリターゲットリストの列 条項
さらに読む：
- キーで集計するときに、従属列を `GROUP BY`から除外できないのはなぜですか？
WHEREでの状態 句はHAVINGに移動する必要があります 集計関数の結果を参照するため（後 WHERE 適用された）。また、出力列を参照することはできません （列エイリアス）HAVING 句。ここでは、入力列のみを参照できます。したがって、式を繰り返す必要があります。マニュアル：
出力列の名前を使用して、
ORDER BYの列の値を参照できます。 およびGROUP BY句はありますが、WHEREにはありません またはHAVING条項;そこで、代わりに式を書き出す必要があります。
FROMのテーブルの順序を逆にしました 句を追加し、構文を少しクリーンアップして、混乱を少なくしました。 USING ここでは単なる表記上の便宜です。
LEFT JOINを使用しました JOINの代わりに 、したがって、ログのないライセンスを除外することはありません。
null以外の値のみがcount()によってカウントされます 。 関連するエントリを数えたいので テーブル"Log"内 count(b.license_id)を使用する方が安全で、わずかに安価です。 。この列は結合で使用されるため、列をnullにできるかどうかを気にする必要はありません。
count(*) まだ短く、わずかに高速です。 1のカウントを取得してもかまわない場合 0の場合 左の表の行は、それを使用してください。
余談ですが、しないことをお勧めします 混合ケース識別子を使用するには 可能であればPostgresで。エラーが発生しやすい。