From 06b58974c2bc447d01b8f53d824b2cf392f06b10 Mon Sep 17 00:00:00 2001 From: Tom Lane Date: Wed, 21 Jun 2006 18:30:19 +0000 Subject: [PATCH] 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. --- src/backend/parser/analyze.c | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/src/backend/parser/analyze.c b/src/backend/parser/analyze.c index 95b2ae4e8f..fcb9354b54 100644 --- 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 -- 2.39.5