Added to TODO:
* Fix self-referential UPDATEs seeing inconsistent row versions in
read-committed mode
http://archives.postgresql.org/pgsql-hackers/2007-05/msg00507.php
---
Richard Huxton wrote:
> Florian G. Pflug wrot
Florian G. Pflug wrote:
Is there consensus what the correct behaviour should be for
self-referential updates in read-committed mode? Does the SQL Spec
have anything to say about this?
This seems to have gone all quiet. Do we need a TODO to keep a note of
it? Just "correct behaviour for self-r
Richard Huxton wrote:
Hiroshi Inoue wrote:
Florian G. Pflug wrote:
I think there should be a big, fat warning that self-referential
updates have highly non-obvious behaviour in read-committed mode,
and should be avoided.
It seems pretty difficult for PostgreSQL rule system to avoid such
kin
Hiroshi Inoue wrote:
Florian G. Pflug wrote:
I think there should be a big, fat warning that self-referential
updates have highly non-obvious behaviour in read-committed mode,
and should be avoided.
It seems pretty difficult for PostgreSQL rule system to avoid such
kind of updates. I'm suspi
Florian G. Pflug wrote:
Richard Huxton wrote:
Richard Huxton wrote:
Heikki Linnakangas wrote:
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 t
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 norm
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
Richard Huxton 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 nor
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
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
Hiroshi Inoue wrote:
Heikki Linnakangas wrote:
Hiroshi Inoue wrote:
Concurrently updating an updatable view seems to cause
an unexpected result. Is it a known issue?
Looks right to me. What did you expect?
Shouldn't the last response
(session-2)
UPDATE 1
be
(seesion-2)
Heikki Linnakangas wrote:
> Hiroshi Inoue wrote:
>> Concurrently updating an updatable view seems to cause
>> an unexpected result. Is it a known issue?
>
> Looks right to me. What did you expect?
Shouldn't the last response
(session-2)
UPDATE 1
be
(seesion-2)
UPDAT
Hiroshi Inoue wrote:
> Concurrently updating an updatable view seems to cause
> an unexpected result. Is it a known issue?
Looks right to me. What did you expect?
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)-
Hi developers,
Concurrently updating an updatable view seems to cause
an unexpected result. Is it a known issue?
=> select version();
version
---
PostgreSQL 8.2.1 on i686-pc-mingw32, compiled
14 matches
Mail list logo
