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