Re: [HACKERS] Continue transactions after errors in psql

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Richard Huxton <dev(at)archonet(dot)com>
Cc: Michael Paesold <mpaesold(at)gmx(dot)at>, Greg Sabino Mullane <greg(at)turnstep(dot)com>, pgsql-hackers(at)postgresql(dot)org, pgsql-patches(at)postgresql(dot)org
Subject: Re: [HACKERS] Continue transactions after errors in psql
Date: 2005-04-26 14:35:26
Message-ID: 1814.1114526126@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

Richard Huxton <dev(at)archonet(dot)com> writes:
> Michael Paesold wrote:
>> I just don't see why non-interactive mode does need such a switch
>> because there is no way to check if there was an error. So just put two
>> queries there and hope one will work?

> DROP TABLE foo;
> CREATE TABLE foo...

Unconvincing. What if the drop fails for permission reasons, rather
than because the table's not there? Then the CREATE will fail too
... but now the script bulls ahead regardless, with who knows what
bad consequences.

I would far rather see people code explicit markers around statements
whose failure can be ignored. That is, a script that needs this
behavior ought to look like

BEGIN;
\begin_ignore_error
DROP TABLE foo;
\end_ignore_error
CREATE ...
...
COMMIT;

where I'm supposing that we invent psql backslash commands to cue
the sending of SAVEPOINT and RELEASE-or-ROLLBACK commands. (Anyone
got a better idea for the names than that?)

Once you've got such an infrastructure, it makes sense to allow an
interactive mode that automatically puts such things around each
statement. But I can't really see the argument for using such a
behavior in a script. Scripts are too stupid.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Joshua D. Drake 2005-04-26 14:44:13 Re: [HACKERS] Continue transactions after errors in psql
Previous Message Michael Paesold 2005-04-26 14:30:45 Re: [HACKERS] Continue transactions after errors in psql

Browse pgsql-patches by date

  From Date Subject
Next Message Joshua D. Drake 2005-04-26 14:44:13 Re: [HACKERS] Continue transactions after errors in psql
Previous Message Michael Paesold 2005-04-26 14:30:45 Re: [HACKERS] Continue transactions after errors in psql