Chris Bitmead <chris@bitmead.com> writes:
> Another observation is that if the WHERE clause is successful, it seems
> to update the first record in the target relation that it finds which is
> a pretty random result.
Wouldn't surprise me --- leastwise, you will get a random one of the
input ctid values emitted into the aggregated SELECT row. Offhand I'd
have expected the last-scanned one, not the first-scanned, but the
point is that the behavior is dependent on the implementation's choice
of scanning order. This is exactly the uncertainty that the check for
"attribute must be GROUPed or used in an aggregate function" is designed
to protect you from. But ctid is (currently) escaping that check.
It seems to me that we have two reasonable ways to proceed:
1. Forbid aggregates at the top level of UPDATE. Then you'd need to do
a subselect, perhaps something likeUPDATE fooSET bar = (SELECT min(f1) FROM othertab WHERE othertab.keycol =
foo.keycol)WHEREcondition-determining-which-foo-rows-to-update
if you wanted to use an aggregate. This is pretty ugly, especially so
if the outer WHERE condition is itself dependent on scanning othertab
to see if there are matches to the foo row.
2. Do an implicit GROUP BY ctid as I suggested last night. I still
don't see any holes in that idea, but I am still worried that there
might be one.
regards, tom lane
