How to use column values set in update in subsequent set clauses and in
subqueries in subsequent row updates?
I tried
set transaction isolation level read uncommitted;
create temp table test1 ( a int, b int) on commit drop;
insert into test1 values(1,2);
update test1 set a=4, b=a ;
select * fro
2009/12/19 Andrus :
>
> set transaction isolation level read uncommitted;
the "isolation level" is for specifying what rows are visible no for columns.
besides, postgres doesn't implement "read uncommitted"
> update test1 set a=4, b=a ;
>
> b value is 1 but must be 4.
no. b value "must be" 1, yo
On Dec 19, 2009, at 11:24 AM, Andrus wrote:
set transaction isolation level read uncommitted;
create temp table test1 ( a int, b int) on commit drop;
insert into test1 values(1,2);
update test1 set a=4, b=a ;
select * from test1
b value is 1 but must be 4.
How to use updated value ?
The probl
Christophe Pettus writes:
> On Dec 19, 2009, at 11:24 AM, Andrus wrote:
>> update test1 set a=4, b=a ;
>> How to use updated value ?
> The problem here isn't the transaction isolation level. The order of
> evaluation in an UPDATE statement is (for practical purposes):
> Evaluate all of the
I would be quite surprised if there are any SQL databases that do this
differently.
FoxPro's and probably dBase's do it differently.
CREATE CURSOR t ( a i, b i )
INSERT INTO t VALUES (1,2)
UPDATE t SET a=3, b=a
SELECT * FROM t
returns 3 for b
Andrus.
--
Sent via pgsql-general mailing list
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 ne
On Dec 19, 2009, at 3:34 PM, Andrus wrote:
FoxPro's and probably dBase's do it differently.
Of course, FoxPro and related are not actually relational databases;
they're flat-file managers which use comamnds which somewhat resemble
the SQL syntax.
--
-- Christophe Pettus
x...@thebuild.
On Dec 19, 2009, at 4:06 PM, Andrus wrote:
1. In my case b expression needs values from previous rows updated
in this same command before:
b= (select sum(a) from test1 where
)
I believe there is a misunderstanding as to what "read committed"
isolation level means. Read committed mea
You cannot access new values of a particular row within a single UPDATE
statement, but you do see new values done in the same transaction.
This is explain in some detail in the documentation:
http://www.postgresql.org/docs/8.4/interactive/transaction-iso.html#XACT-READ-COMMITTED
I tried
dro
On Sun, Dec 20, 2009 at 2:12 AM, Andrus wrote:
>> You cannot access new values of a particular row within a single UPDATE
>> statement, but you do see new values done in the same transaction.
>> This is explain in some detail in the documentation:
>>
>>
>> http://www.postgresql.org/docs/8.4/inte
You are confusing a few things, and you don't want to hear the
explanations because they are inconvenient.
Andrus wrote:
> 1. In my case b expression needs values from previous rows updated in this
> same command before:
You are confusing "to the left of" and "before".
If you want behaviour that
Hi, Andrus,
First, it does seem that you are expecting PostgreSQL to have the same
behavior as a flat-file manager such as FoxPro (indeed, it seems you'd
like PG to have the behavior of a *specific* flat-file manager).
Despite the superficial similarity in the command syntax, a modern
RD
On Sat, Dec 19, 2009 at 7:16 PM, Christophe Pettus wrote:
>
>> I understand that it is not possible to read previous rows without
>> creating hack using triggers.
>
> As noted above, that's not correct. You cannot access new values of a
> particular row within a single UPDATE statement, but you d
13 matches
Mail list logo
