Suppose the following:
create table test (a int primary key);
insert into test values (1);
select * from test;
a
=
1
In Postgresql if you do the following in a transaction (either with
autocommit=off or with an explizit begin):
insert into test values (2); - ok
insert into test values (1); -
Um, the behaviour you are seeing is what would happen in PostgreSQL if
everything were all in one transaction. What you show for Oracle is what
would happen if each statement were in it's own transaction.
On the postgresql server here, without transactions:
create temp table test (a int primary
On Mon, 14 Jul 2003, Jörg Schulz wrote:
Suppose the following:
create table test (a int primary key);
insert into test values (1);
select * from test;
a
=
1
In Postgresql if you do the following in a transaction (either with
autocommit=off or with an explizit begin):
insert into
... I have this feeling the reason Oracle gives this result may
be again because transactions have been switched off!
This snippet comes from the Oracle console:
(table name is a not test / messages are in german)
SQL show autocommit;
autocommit OFF
SQL select * from a;
A
--
Jörg Schulz wrote:
... I have this feeling the reason Oracle gives this result may
be again because transactions have been switched off!
This snippet comes from the Oracle console:
(table name is a not test / messages are in german)
...
SQL select * from a;
A
--
On Mon, 14 Jul 2003, Mike Mascari wrote:
Jörg Schulz wrote:
... I have this feeling the reason Oracle gives this result may
be again because transactions have been switched off!
This snippet comes from the Oracle console:
(table name is a not test / messages are in german)
...
Oracle does not roll back any transaction unless explicitly requested by
the client application. If there are errors while executing statements
inside a transaction, their effect is rolled back, not the whole
transaction. The application can then decide if the successful part of
the transaction is
On Mon, 2003-07-14 at 10:43, Peter Childs wrote:
On Mon, 14 Jul 2003, Mike Mascari wrote:
Jrg Schulz wrote:
... I have this feeling the reason Oracle gives this result may
be again because transactions have been switched off!
This snippet comes from the Oracle console:
(table
Peter Childs wrote:
On Mon, 14 Jul 2003, Mike Mascari wrote:
Jörg Schulz wrote:
Presumably Oracle is not rolling back a duplicate key violation,
allowing the transaction to continue. This is an often requested
feature not present in PostgreSQL.
Bug. Not Feature
Transactions
On 14 Jul 2003 at 5:18, Mike Mascari wrote:
I agree. However a common scenario that has appeared on these lists is
a request for an atomic 'CREATE IF NOT EXISTS, ELSE REPLACE' without
race conditions. Because Oracle doesn't rollback the transaction, it
is implementable in SQL. For PostgreSQL,
This has been discussed for many times on this list, but shortly: when
inserting a new row, there's no previous row to select for update. If
you have 2 concurrent transactions, both of them can execute the select
for update at the same time, select nothing, and then try to insert the
same key, and
On Mon, 2003-07-14 at 04:07, Csaba Nagy wrote:
[snip]
This feature is often requested because it's very useful, especially in
Amen! Give the app developer the opportunity to travel down a different
code path if s/he tries, for example, to insert a duplicate key.
[snip]
The main reason why
12 matches
Mail list logo
