Re: ERROR: ExecEvalAggref

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: eric soroos <eric-psql(at)soroos(dot)net>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: ERROR: ExecEvalAggref
Date: 2003-01-29 06:30:19
Message-ID: 20189.1043821819@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

eric soroos <eric-psql(at)soroos(dot)net> writes:
> update dl_profile set
> city= profiler(concat(dl_event._eventDate,dl_event.city))::text
> from dl_event where dl_event._donorNum='385'
> and dl_profile._donorNum='385'
> and dl_event._flDeleted='f'
> ERROR: ExecEvalAggref: no aggregates in this expression context

In general, aggregates at the top level of an UPDATE are ill-defined
(the SQL spec prohibits them outright, and probably we should too).
You will realize the problem when you ask yourself "exactly what
set of rows is the aggregate aggregating over? How would I control
what that set is, separately from controlling which rows of dl_profile
get updated?"

You will perhaps have better luck with a query structured like

update dl_profile set
city = (select profiler(...) from ... where FOO)
where BAR

Here, FOO controls the set of rows aggregated over, and BAR defines
what set of rows of dl_profile get updated. Note you can use
outer references to the current row of dl_profile in the sub-select.

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Stephan Szabo 2003-01-29 06:39:57 Re: need much better query perfomance
Previous Message Stephan Szabo 2003-01-29 06:20:13 Re: What happens when you run out of transaction ID's ???