Re: different transaction handling between postgresql and

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 Oracle console:
> > > (table name is "a" not "test" / messages are in german)
> > >
> > ...
> >
> > > SQL> select * from a;
> > >
> > > A
> > > ----------
> > > 1
> > > 3
> > > 4
> > > 2
> >
> > 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 must be all or nothing. If one step fails for what
> ever reason all steps must be failed and rolled back. While in this simple
> case ignoring the statment may look fine in more complex examples (where
> the is more data in the table...) this can mean data loss and massive
> problems!

Wrong. Oracle is NOT ignoring the error, it responds with an error
message, which is telling the user that the current query had an error
(in Java you get an exception).
Now the application can decide if this means an error for the whole
transaction or just for the current query. If your application rolles
back on all errors, this is the exact behavior which is forced on you by
postgres. But if the application can decide the last error is ignorable
(which can be true in some cases, as in this example), and the
transaction is still valid despite of the latest error, then you get in
a lot of cases more elegant/readable application code. You could also
easily log the failed inserts and do something else on that data, while
the valid entries are committed.
I see this as a feature, because the programmer gets more control, more
options, and the original behavior is still implemented.

Cheers,
Csaba.

>
> Peter Childs
>
> >
> > Mike Mascari
> > mascarm(at)mascari(dot)com
> >
> >
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 7: don't forget to increase your free space map settings
> >
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
>