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 it will happen.
Jim C. Nasby wrote:
Show quoted text
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.