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

Re: Single-Transaction Utility options

From: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: pgsql-patches(at)postgresql(dot)org
Subject: Re: Single-Transaction Utility options
Date: 2005-12-16 22:05:06
Message-ID: 20051216220506.GB28739@surnet.cl (view raw or flat)
Thread:
Lists: pgsql-patches
Simon Riggs wrote:
> On Fri, 2005-12-16 at 16:04 -0300, Alvaro Herrera wrote:
> > Simon Riggs wrote:
> > > The following patches add a -N option to psql and pgrestore.
> > > 
> > > This option adds a BEGIN at the start and a COMMIT at the end of all
> > > commands, causing all statements to be executed as a single transaction.
> > 
> > Why use it around the whole file and not only around that particular
> > table's operations?  
> 
> You could. That just behaves slightly differently.
> 
> Maybe we should have options for both?

Are they different enough to warrant having two switches?  IIRC the
point was to have the COPY in the same transaction as the CREATE TABLE,
right?  In what way is it worse to have each table in its own
transaction?

> > Also why force it to activate the abort-on-error
> > mode?
> 
> For what reason would you want it to keep running?

To restore the rest of the tables in the dump I presume ... I mean, the
behaviors are orthogonal really (_if_ you take the stance that this
should be used on a per table basis rather than a file basis, that is.
Because if you abort the transaction then clearly there's no point in
keep running, as everything will be rejected by the server anyway.)

-- 
Alvaro Herrera                                http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

In response to

pgsql-patches by date

Next:From: Tom LaneDate: 2005-12-16 22:18:20
Subject: Re: Single-Transaction Utility options
Previous:From: Alvaro HerreraDate: 2005-12-16 21:56:00
Subject: Re: Win32 gettimeofday() comment patch

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