Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] Continue transactions after errors in psql

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Richard Huxton <dev(at)archonet(dot)com>,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 15:03:40
Message-ID: 426E584C.3080003@dunslane.net (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches

Tom Lane wrote:

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

That's a lot of work. In this particular case I would actually like to 
see us provide "DROP IF EXISTS ..." or some such.

My instinct on this facility is that distinguishing between interactive 
and noninteractive use is likely to be highly confusing. So I would 
favor behaviour that is consistent and defaults to off.

cheers

andrew



In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2005-04-26 15:15:35
Subject: Re: bitmapscan test, no success, bs is not faster
Previous:From: Tom LaneDate: 2005-04-26 14:57:49
Subject: Re: [HACKERS] Continue transactions after errors in psql

pgsql-patches by date

Next:From: Tom LaneDate: 2005-04-26 15:19:51
Subject: Re: [HACKERS] Continue transactions after errors in psql
Previous:From: Tom LaneDate: 2005-04-26 14:57:49
Subject: Re: [HACKERS] Continue transactions after errors in psql

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group