Обсуждение: ERROR: ExecutePlan: (junk) `ctid' is NULL!
stats=> UPDATE Tsummary stats-> SET date = last_date stats-> , project_id = :ProjectID stats-> , work_units = work_for_day stats-> , participants_new = (SELECT count(*) FROM email_rank WHERE project_id = :ProjectID stats(> AND first_date = ps.last_date) stats-> , teams_new = (SELECT count(*) FROM team_rank WHERE project_id = :ProjectID stats(> AND first_date = ps.last_date) stats-> FROM project_statsrun ps stats-> WHERE ps.project_id = :ProjectID stats-> ; UPDATE 0 stats=> stats=> \echo email_contrib_today email_contrib_today 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! Uhm... what exactly is that supposed to mean? More important, how do I fix it? :) -- Jim C. Nasby (aka Decibel!) jim@nasby.net Member: Triangle Fraternity, Sports Car Club of America Give your computer some brain candy! www.distributed.net Team #1828 Windows: "Where do you want to go today?" Linux: "Where do you want to go tomorrow?" FreeBSD: "Are you guys coming, or what?"
"Jim C. Nasby" <jim@nasby.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 ...
regards, tom lane
On Tue, Apr 29, 2003 at 06:36:59PM -0400, Tom Lane wrote:
> "Jim C. Nasby" <jim@nasby.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.
--
Jim C. Nasby (aka Decibel!) jim@nasby.net
Member: Triangle Fraternity, Sports Car Club of America
Give your computer some brain candy! www.distributed.net Team #1828
Windows: "Where do you want to go today?"
Linux: "Where do you want to go tomorrow?"
FreeBSD: "Are you guys coming, or what?"
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 itwill happen. Jim C. Nasby wrote: > On Tue, Apr 29, 2003 at 06:36:59PM -0400, Tom Lane wrote: > >>"Jim C. Nasby" <jim@nasby.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.