Hiroshi Inoue wrote:
Richard Huxton wrote:
Heikki Linnakangas wrote:
The problem is that the new tuple version is checked only against the
condition in the update rule, id=OLD.id, but not the condition in the
original update-claus, dt='a'.
Yeah, that's confusing :(.
Bit more than just normal rule confusion I'd say. Try the following
two statements in parallel (assuming you've just run the previous):
UPDATE test SET dt='c';
UPDATE test SET dt='x' FROM test t2 WHERE test.id=t2.id AND t2.dt='b';
This isn't a problem with the view mechanism - it's a problem with
re-checking clauses involving subqueries or joins I'd guess.
I don't understand the PostgreSQL specific *FROM* clause correctly.
Currently the relations in the *FROM* clause seem to be read only
and UPDATE operations seem to acquire no tuple level lock on them.
Yes, the above query is equivalent to:
UPDATE test SET dt='x' WHERE id IN (SELECT id FROM test WHERE dt='b');
There are some expressions more naturally expressed as a set of where
conditions though, and I think the "FROM" is just to provide a place to
name them.
The FROM form seemed to be the more natural match to the plan your view
was generating - I'm not sure which the plan transformation process
produces.
--
Richard Huxton
Archonet Ltd
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
