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, ...
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 |