Re: How to use read uncommitted transaction level and set update order

From: "Andrus" <kobruleht2(at)hot(dot)ee>
To: "Christophe Pettus" <xof(at)thebuild(dot)com>
Cc: <pgsql-general(at)postgresql(dot)org>
Subject: Re: How to use read uncommitted transaction level and set update order
Date: 2009-12-20 00:06:03
Message-ID: E2CCA11808E34ADC9E77B039FF9BF4B4@andrusnotebook
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

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.

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Postgres User 2009-12-20 00:08:32 Re: Selecting from table into an array var
Previous Message Andrus 2009-12-19 23:34:35 Re: How to use read uncommitted transaction level and set update order