neilc@samurai.com (Neil Conway) writes:
> On Mon, 2006-11-27 at 11:39 +0100, Markus Schaber wrote:
>> Hmm, I guess that the new RETURNING feature of PostgreSQL 8.2 can help
>> with this problem.
>
> I don't see how. The basic problem is that SQL is nondeterministic in
> general; you can't safely assume that evaluating the same sequence of
> SQL statements on all nodes will yield the same final database state.
Well, RETURNING means that there's some place which receives the
return set, which means that there is, in principle, a place where the
data would be capturable.
But it is important to point out that the "nondeterministic"
possibilities do not end with NOW() or CURRENT_TIMESTAMP; other
nondeterministic things that can cause trouble include:
a) A sequence value, which is set *somewhat* invisibly,
b) A query of the form
insert into some_table (select * from a_table);
where the SELECT subquery is not of the form:
SELECT [fields] FROM [a_table] WHERE [Fully Deterministic Criterion]
ORDER BY [some criterion suitable to be a primary key for the result set]
LIMIT [anything];
If you could capture the RETURNING data, and replicate that, well,
that at least provides a way to get around the nondeterminism problem.
That would work out well for both INSERT and DELETE. I'm not sure
it'll work as well for UPDATE; that doesn't return both old and new
column values :-(.
--
"cbbrowne","@","acm.org"
http://linuxdatabases.info/info/internet.html
"Problem solving under linux has never been the circus that it is
under AIX." -- Pete Ehlke in comp.unix.aix
