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
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 ??? |