Disallow aggregate functions in UPDATE commands (unless within a sub-SELECT).

This is disallowed by the SQL spec because it doesn't have any very sensible
interpretation.  Historically Postgres has allowed it but behaved strangely.
As of PG 8.1 a server crash is possible if the MIN/MAX index optimization gets
applied; rather than try to "fix" that, it seems best to just enforce the
spec restriction.  Per report from Josh Drake and Alvaro Herrera.

diff --git a/src/backend/parser/analyze.c b/src/backend/parser/analyze.c
index 95b2ae4e8f88c51ab6ca14bca852741d2b6e5124..fcb9354b54b5fd1a858ce31b71dd09543b0b6f4a 100644 (file)
--- a/src/backend/parser/analyze.c
+++ b/src/backend/parser/analyze.c
@@ -2333,9 +2333,16 @@ transformUpdateStmt(ParseState *pstate, UpdateStmt *stmt)
        qry->jointree = makeFromExpr(pstate->p_joinlist, qual);
 
        qry->hasSubLinks = pstate->p_hasSubLinks;
-       qry->hasAggs = pstate->p_hasAggs;
+
+       /*
+        * Top-level aggregates are simply disallowed in UPDATE, per spec.
+        * (From an implementation point of view, this is forced because the
+        * implicit ctid reference would otherwise be an ungrouped variable.)
+        */
        if (pstate->p_hasAggs)
-               parseCheckAggregates(pstate, qry);
+               ereport(ERROR,
+                               (errcode(ERRCODE_GROUPING_ERROR),
+                                errmsg("cannot use aggregate function in UPDATE")));
 
        /*
         * Now we are done with SELECT-like processing, and can get on with