Bruce Momjian <pgman@candle.pha.pa.us> writes:
> I thought the aggregate would be generated on all rows in the table in
> the pre-transaction version of the table, so in this example:
> regression=# update t2 set f2 = min(f1) from t1;
> It places the minimum value of t1.f1 in all t2.f2 rows.
This actually is not the most interesting example, because the aggregate
doesn't depend at all on t2. Try this instead:
regression=# create table t1(f1 int);
CREATE
regression=# create table t2(f1 int);
CREATE
regression=# insert into t1 values(-1);
INSERT 400599 1
regression=# insert into t1 values(-2);
INSERT 400600 1
regression=# insert into t1 values(-3);
INSERT 400601 1
regression=# insert into t2 values(-1);
INSERT 400602 1
regression=# insert into t2 values(-2);
INSERT 400603 1
regression=# insert into t2 values(-3);
INSERT 400604 1
regression=# update t2 set f1 = count(*) from t1;
UPDATE 1
regression=# select * from t2;f1
-----2-3 9
(3 rows)
regression=#
This is certainly broken, but what's the correct behavior?
Or how about this, which doesn't even use an aggregate:
regression=# update t2 set f1 = t1.f1 from t1;
UPDATE 3
regression=# select * from t2;f1
-----1-1-1
(3 rows)
regression=#
That's surprising too, perhaps, but what would you have expected
and why?
There's a reason why SQL99 forbids joins and aggregates in UPDATE ...
they're not always well-defined.
I had a proposal (GROUP BY ctid) in the older thread for fixing the
aggregate misbehavior, but it doesn't solve the more general problem
of a join that produces multiple matches for the same target row.
Seems like that probably ought to draw an error.
regards, tom lane
