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 th
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 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 PostgreS
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
>
>
On Mon, 2003-07-14 at 10:43, Peter Childs wrote:
> 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 Oracl
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, 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 ge
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
>
> ... 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
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):
>
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 k
11 matches
Mail list logo
