From: | eric soroos <eric-psql(at)soroos(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: ERROR: ExecEvalAggref |
Date: | 2003-01-29 18:28:44 |
Message-ID: | 94844485.1168286372@[4.42.179.151] |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
> In general, aggregates at the top level of an UPDATE are ill-defined
> (the SQL spec prohibits them outright, and probably we should too).
In cases like this, it's probably better if it had never worked rather than failing for no apparent reason once it got into production.
> You will perhaps have better luck with a query structured like
>
> update dl_profile set
> city = (select profiler(...) from ... where FOO)
> where BAR
I've recast this as the following to allow for more fields without adding a subselect for each field.
update dl_profile set
_incomingSubject= calc._incomingSubject
...
from (select
profiler(concat(dl_event._eventDate,dl_event._incomingSubject) as _incomingSubject
...
from dl_event where dl_event._donorNum='6'
and dl_event._flDeleted='f'
) as calc
where dl_profile._donorNum='6';
This is working now, thanks for the help.
eric
From | Date | Subject | |
---|---|---|---|
Next Message | Francisco J Reyes | 2003-01-29 18:34:58 | Re: how much memory to allot to postgres? |
Previous Message | Neil Conway | 2003-01-29 18:25:49 | Re: Query gone wild |