Skip site navigation (1) Skip section navigation (2)

Re: Now PostgreSQL recovers from errors within trns

From: Don Baccus <dhogaza(at)pacifier(dot)com>
To: hstenger(at)ieee(dot)org, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Now PostgreSQL recovers from errors within trns
Date: 2000-07-31 17:05:12
Message-ID: 3.0.1.32.20000731100512.013b0140@mail.pacifier.com (view raw or flat)
Thread:
Lists: pgsql-hackers
At 02:10 PM 7/31/00 -0300, hstenger(at)adinet(dot)com(dot)uy wrote:
>Tom Lane wrote:
>> 
>> hstenger(at)adinet(dot)com(dot)uy writes:
>> > My goal is to make the backend accept erroneous commands, not falling
>> > in *ABORT STATE*, but rolling back automatically, & continue accepting
>> > commands.
>> 
>> The way you're doing it, you might as well just not use transaction
>> blocks at all.  I don't think wiping out the effects of all preceding
>> commands within the transaction counts as "recovering from an error".
>
>Ok, maybe I exagerated, but kind of solves my problem. GeneXus, my CASE tool,
>will send begin/commit pairs, so I must 'recover' automatically. I aimed
>DB2-like behaviour, which I was told, aborts on errors within
transactions, but
>remains in a runnable state. Don't you consider it valueable whatsoever?

Well, Postgresql's behavior isn't SQL92 compliant, but neither is the 
behavior you want.  I far prefer the current non-standard behavior.
Eventually,
of course, PG should conform to SQL92.

GeneXus should be catching the error and issuing a rollback if that's
the behavior it expects.



- Don Baccus, Portland OR <dhogaza(at)pacifier(dot)com>
  Nature photos, on-line guides, Pacific Northwest
  Rare Bird Alert Service and other goodies at
  http://donb.photo.net.

In response to

Responses

pgsql-hackers by date

Next:From: hstengerDate: 2000-07-31 17:10:16
Subject: Re: Now PostgreSQL recovers from errors within trns
Previous:From: Tom LaneDate: 2000-07-31 15:08:03
Subject: Re: Now PostgreSQL recovers from errors within trns

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group