Re: different transaction handling between postgresql and

From: Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com>
To: Peter Childs <blue(dot)dragon(at)blueyonder(dot)co(dot)uk>
Cc: Mike Mascari <mascarm(at)mascari(dot)com>, Jörg Schulz <jschulz(at)sgbs(dot)de>, <pgsql-general(at)postgresql(dot)org>
Subject: Re: different transaction handling between postgresql and
Date: 2003-07-14 15:37:22
Message-ID: 20030714083259.Q61305-100000@megazone.bigpanda.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general


On Mon, 14 Jul 2003, 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 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

Well as far as spec compliance goes it's not. Our behavior is mostly
compliant by explicitly saying that all errors are unrecoverable ones.
The spec explicitly allows (or one could say expects) behavior like
Oracle's for any error that doesn't occur on the execution of the commit
itself. As to whether it's a good idea or not, ...

In response to

Browse pgsql-general by date

  From Date Subject
Next Message u15074 2003-07-14 16:34:35 What is the max size for a bytea field?
Previous Message apb18 2003-07-14 15:03:27 Detoasting and memory usage