Christophe,
> It's not clear why you need to do it this way, though. Presumably, since
> you did some kind of computation that came up with the number '4', you
> can assign that value instead of using the field a:
>
> UPDATE test1 set a=4, b=4;
There are two reasons:
1. In my case b expression needs values from previous rows updated in this
same command before:
b= (select sum(a) from test1 where
<select_test1_previously_updated_rows_condition> )
I understood from replies that
set transaction isolation level read uncommitted;
in PostgreSql is broken: it sets silently committed isolation level.
I understand that it is not possible to read previous rows without creating
hack using triggers.
2. In my planned UPDATE statement instead of 4 there is an expression
containing one big CASE WHEN expression with many WHEN .. THEN clauses.
This command takes several hundreds of lines.
Your solution requires repeating this expression two times and thus makes
sql difficult to read.
It seems that splitting update statement into separate UPDATE commands in
proper order, one for every column and commiting transaction after every
update is the only solution.
Fortunately in my case it is allowed to split every column update to
separate transaction.
Andrus.