Re: transactions on Postgresql

From: lachesis(at)ignmail(dot)com (Dave Robinson)
To: pgsql-general(at)postgresql(dot)org
Subject: Re: transactions on Postgresql
Date: 2001-05-29 13:55:19
Message-ID: 90af9a8c.0105290555.faf16b9@posting.google.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Vivek Khera <khera(at)kcilink(dot)com> wrote in message news:<x77kz4n9n3(dot)fsf(at)yertle(dot)kciLink(dot)com>...
> >>>>> "DR" == Dave Robinson <lachesis(at)ignmail(dot)com> writes:
>
> >> my problem : if an insert fail, all following insert are aborted :-(
> >>
> >> NB : it's not necessary to me that ALL inserts , will be done
> >> with succes.
> >> my question is : if a BAD insert fail , how can i do for doing
> >> other inserts who may be are GOOD ?
> >>
> >> thanks a lot for help ;-)
>
>
> DR> You want to look at wrapping your do statement into an eval block you
> DR> can then capture the insert death in $@
>
> Perl does not die; Postgres goes into ABORT STATE after the first
> failure, and that is his problem. The only real way around this is to
> not put the whole thing in a transaction.

Doh! Sorry, somehow I missed the fact that it was in a transaction.
If the code isn't put into a transaction then the eval-capture stuff
should be done.
The other option is if the conditions which generate the BAD insert
can be captured, they can be tested for. The test can then be used to
decide whether to do the insert at all for that line.

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Ian Harding 2001-05-29 14:03:36 Re: UPDATE keyword
Previous Message Tom Lane 2001-05-29 13:46:03 Re: Re: [SQL] Difficult SQL Statement