The group clause has to contain all fields that are explicitly queried for non-MySQL databases. This will cause the module to stop working on PostgreSQL.

From the PostgreSQL doc (http://www.postgresql.org/docs/9.0/static/sql-select.html#SQL-HAVING)

Each column referenced in condition must unambiguously reference a grouping column, unless the reference appears within an aggregate function.

So since the only having left is using count(tag_id), it should work imho.
However if it's indeed a problem we could also use count(core_content_id) or even count(1) and get the same result.

I'll have to test it then, but I know there are issues for the non-MySQL
databases when there are columns missing in the group clause.. I'd say I'd
expect the same for SQL Server, but the query isn't even valid for that
environment.

On Saturday, April 20, 2013, Thomas Hunziker wrote:

From the PostgreSQL doc (
http://www.postgresql.org/docs/9.0/static/sql-select.html#SQL-HAVING)

Each column referenced in condition must unambiguously reference a
grouping column, unless the reference appears within an aggregate function.

So since the only having left is using count(tag_id), it should work
imho.
However if it's indeed a problem we could also use *count(core_content_id)

• or even count(1) and get the same result.

—
Reply to this email directly or view it on GitHub#1017 (comment)
.

I would be interested in your test results as I can't test it myself.

Looking at the doc for MS SQL (http://msdn.microsoft.com/en-us/library/ms180199.aspx) there is an example which looks quite similar to what we do:

SELECT SalesOrderID, SUM(LineTotal) AS SubTotal
FROM Sales.SalesOrderDetail
GROUP BY SalesOrderID
HAVING SUM(LineTotal) > 100000.00
ORDER BY SalesOrderID ;

So I would say MS SQL does support using a reference that is not in the group by within an aggregation.
Thinking about it, it wouldn't even make much sense otherwise.

Updated PR so the commands are in a logical order (where and join before group).

Fixed in master. Thanks!