Re: Unexpected *ABORT STATE*

I think that for that to behave as you would like, each executed line would have
to be its own transaction nested inside the larger transaction that you
explicitly declared.  An error on one line would cause an implicit rollback of
everything done as a result of executing that one line, success would implicitly
commit that line, although it wouldn't be fully committed until you reach the
end of the outer explicit block.  Does that sound like the behaviour you want?
If so, then  you'll need to wait at least until Postgresql supports nested
transactions before this would even be a possibility.




Joseph Shraibman <jks%selectacast.net@interlock.lexmark.com> on 07/31/2001
03:23:16 PM

To:   Jan Wieck <JanWieck%yahoo.com@interlock.lexmark.com>
cc:   Mike Finn <mike.finn%tacticalExecutive.com@interlock.lexmark.com>,
      pgsql-general%postgresql.org@interlock.lexmark.com (bcc: Wesley
      Sheldahl/Lex/Lexmark)
Subject:  Re: [GENERAL] Unexpected *ABORT STATE*


Jan Wieck wrote:
>
> Joseph Shraibman wrote:
> > Mike Finn wrote:
> > >
> >
> > > problem but I was wondering why this occurs, and if it is on the todo list
to
> > > fix.
> >
> > It occurs because once an error happens all the changes that have been
> > made may not mean anything, so the transaction must be rolled back.
> > Maybe there is something that could be set to interactive programs like
> > psql can disable this?  If not there should be, becuase I too have been
> > anoyed with a long interactive session having to be restarted because of
> > a typo.
>
>     There is absolutely nothing that could be set to "disable" it
>     and continue the transaction. This is because the system  has
>     no  idea  how  to  distinguish  between  a  syntax typo and a
>     duplicate key error for example. Both are simply  and  ERROR.
>     Now  for a typo it'd not be critical, but for a dupkey - er -
>     the heap typle is there, not  all  indexes  might  have  been
>     processed  and  for sure the referential integrity constraint
>     triggers  and  other  stuff  haven't  been  run.  That's   an
>     inconsistent  DB state, isn't it? Are you sure you want that?

Then that command would fail and not alter the state of the db as seen
within the transaction block.  The previous alterations withing the
transaction block would still be there, waiting to be commited.

>


--
Joseph Shraibman
jks@selectacast.net
Increase signal to noise ratio.  http://www.targabot.com

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://www.postgresql.org/search.mpl