On 2015-12-01 05:00, David Rowley wrote:
> We already allow a SELECT's target list to contain non-aggregated columns
> in a GROUP BY query in cases where the non-aggregated column is
> functionally dependent on the GROUP BY clause.
>
> For example a query such as;
>
> SELECT p.product_id,p.description, SUM(s.quantity)
> FROM product p
> INNER JOIN sale s ON p.product_id = s.product_id
> GROUP BY p.product_id;
>
> is perfectly fine in PostgreSQL, as p.description is functionally dependent
> on p.product_id (assuming product_id is the PRIMARY KEY of product).
This has come up before (on other forums, at least), and my main concern
has been that unlike the case where we go from throwing an error to
allowing a query, this has a chance to make the planning of currently
legal queries slower. Have you tried to measure the impact of this on
queries where there's no runtime gains to be had?
.m
