Re: Transaction aborts on syntax error.

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: josh(at)agliodbs(dot)com
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Transaction aborts on syntax error.
Date: 2004-02-14 01:39:28
Message-ID: 200402140139.i1E1dS610914@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Josh Berkus wrote:
> Bruce,
>
> > > So, whatever "error handling mode" conveniences we wish to put in should
> > > be put in on the client side.
> >
> > Added to TODO:
> >
> > ????????* Use nested transactions to prevent syntax errors from aborting
> > ???????? ?a transaction
>
> Hmmm .... I'm not sure how you arrived at this wording for the TODO. How are
> we defining a "syntax error"?

Parser error, I would say. Misspelling a table name, perhaps. Not sure
on that one, but clearly this opens a can of worms we will have to deal
with someday.

> I write a lot of procedures for T-SQL with error-controlled rollback, and a
> few for Oracle. I can tell you that all of the errors which I anticipate
> for, and thus do not abort the operation when I encounter, fall into one of
> these types:
> 1) Constraint conflict: duplicate key.
> 2) Constraint/Data Type conflict: bad value format
> 3) Duplicate object name
> 4) Object not found
> 5) Lock conflict

Certainly this will never be the default. My guess is that for these
cases, you will have to code the transaction/subtransaction yourself in
your script.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Christopher Kings-Lynne 2004-02-14 04:16:28 Re: pg_restore problems and suggested resolution
Previous Message Tom Lane 2004-02-14 00:04:00 Re: Proposed Query Planner TODO items