From: | Dennis Gearon <gearond(at)cvc(dot)net> |
---|---|
To: | jim(at)nasby(dot)net |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: ERROR: ExecutePlan: (junk) `ctid' is NULL! |
Date: | 2003-04-30 16:18:02 |
Message-ID: | 3EAFF73A.5080206@cvc.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
That looks REALLY useful. I haven't gotten to the point of needing to set more than one field at a time, yet, but I bet it will happen.
Jim C. Nasby wrote:
> On Tue, Apr 29, 2003 at 06:36:59PM -0400, Tom Lane wrote:
>
>>"Jim C. Nasby" <jim(at)nasby(dot)net> writes:
>>
>>>stats=> UPDATE Tsummary
>>>stats-> SET participants = count(distinct credit_id)
>>>stats-> , teams = count(distinct team_id)
>>>stats-> FROM email_contrib_today ect
>>>stats-> WHERE ect.project_id = :ProjectID
>>>stats-> ;
>>>ERROR: ExecutePlan: (junk) `ctid' is NULL!
>>
>>We really oughta reject UPDATE commands with aggregates at the top
>>level. It's not well-defined, it's illegal per SQL spec, and it tends
>>to get the executor all confused ...
>
>
> The problem is that pgsql doesn't support
>
> UPDATE table
> SET (field1, field2, field3) =
> (SELECT min(blah), max(blah), count(*) FROM table2)
>
> This makes it a real pain to code this using subselects. UPDATE ... FROM
> is real handy to have, but I think there's also plenty of occasions
> where the ability to set multiple fields at once would be very useful
> too.
From | Date | Subject | |
---|---|---|---|
Next Message | Medi Montaseri | 2003-04-30 16:44:41 | Buffer Cache question.... |
Previous Message | Steve Crawford | 2003-04-30 16:15:53 | C-JDBC Clustering Solution |