database/postgres
database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-05-28 05:21:27 +03:00
Code

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

Browse Source 
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.
This commit is contained in:
Tom Lane 2006-06-21 18:30:19 +00:00
parent e582d2ee1a
commit 62ae14545b
1 changed files with 10 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

13
src/backend/parser/analyze.c
View File

@ -6,7 +6,7 @@
* Portions Copyright (c) 1996-2005, PostgreSQL Global Development Group
* Portions Copyright (c) 1994, Regents of the University of California
*
* $PostgreSQL: pgsql/src/backend/parser/analyze.c,v 1.326.2.1 2005/11/22 18:23:12 momjian Exp $
* $PostgreSQL: pgsql/src/backend/parser/analyze.c,v 1.326.2.2 2006/06/21 18:30:19 tgl Exp $
*
*-------------------------------------------------------------------------
*/
@ -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