Patch applied. Thanks.
---
Simon Riggs wrote:
> On Sat, 2005-12-17 at 20:03 +0100, Peter Eisentraut wrote:
> > Simon Riggs wrote:
> > > Changes as discussed. "singletransaction.patch" attached.
> >
> > I meant to ask, why
Patch applied. Thanks.
---
Simon Riggs wrote:
> On Fri, 2005-12-16 at 15:56 -0500, Tom Lane wrote:
> > Simon Riggs <[EMAIL PROTECTED]> writes:
> > > On Fri, 2005-12-16 at 13:59 -0500, Tom Lane wrote:
> > >> Would -1 work,
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> I once considered implementing this myself but found it infeasible for
> some reason I don't remember. Nevertheless I always thought that
> having an atomic restore ought to be a non-optional feature. Are there
> situations where one would not wan
On Sun, 2005-12-18 at 21:51 +0100, Peter Eisentraut wrote:
> Tom Lane wrote:
> > I believe Peter's question was rhetorical: what he meant to point out
> > is that the documentation needs to explain what is the reason for
> > having this switch, ie, in what cases would you use it or not use it?
> >
On Sun, 2005-12-18 at 14:04 -0500, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > On Sat, 2005-12-17 at 20:03 +0100, Peter Eisentraut wrote:
> >> I meant to ask, why is this not the default or only behavior?
>
> > Historically, it didn't work that way, so I hadn't thought to chang
Tom Lane wrote:
> I believe Peter's question was rhetorical: what he meant to point out
> is that the documentation needs to explain what is the reason for
> having this switch, ie, in what cases would you use it or not use it?
> Just saying what it does isn't really adequate docs.
I once consider
Simon Riggs <[EMAIL PROTECTED]> writes:
> On Sat, 2005-12-17 at 20:03 +0100, Peter Eisentraut wrote:
>> I meant to ask, why is this not the default or only behavior?
> Historically, it didn't work that way, so I hadn't thought to change
> that behaviour. We could I suppose... but I'm happy with
On Sat, 2005-12-17 at 20:03 +0100, Peter Eisentraut wrote:
> Simon Riggs wrote:
> > Changes as discussed. "singletransaction.patch" attached.
>
> I meant to ask, why is this not the default or only behavior?
Historically, it didn't work that way, so I hadn't thought to change
that behaviour. We
Simon Riggs wrote:
> Changes as discussed. "singletransaction.patch" attached.
I meant to ask, why is this not the default or only behavior? Your
patch does not contain a documentation update, and so the user has no
information about why to use this option or not.
--
Peter Eisentraut
http://d
On Fri, 2005-12-16 at 15:56 -0500, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > On Fri, 2005-12-16 at 13:59 -0500, Tom Lane wrote:
> >> Would -1 work, or just confuse people?
>
> > That was my preference, I just thought it wouldn't be popular...
> > So I'll happily change that.
>
Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> >> Why use it around the whole file and not only around that particular
> >> table's operations?
>
> > You could. That just behaves slightly differently.
>
> pg_dump does not always produce all the commands affecting a single
> table t
Simon Riggs <[EMAIL PROTECTED]> writes:
>> Why use it around the whole file and not only around that particular
>> table's operations?
> You could. That just behaves slightly differently.
pg_dump does not always produce all the commands affecting a single
table together, so I don't think you ca
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 exec
Simon Riggs <[EMAIL PROTECTED]> writes:
> On Fri, 2005-12-16 at 13:59 -0500, Tom Lane wrote:
>> Would -1 work, or just confuse people?
> That was my preference, I just thought it wouldn't be popular...
> So I'll happily change that.
OK. While you're at it, I didn't like the long name either ;-).
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.
>
On Fri, 2005-12-16 at 13:59 -0500, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > The following patches add a -N option to psql and pgrestore.
>
> -N seems an entirely random name for the switch ... can't we do better?
> I see that -t, -T, -s, -S, -x and -X are all taken, which lets
> Also, I don't actually see any point to this in psql, as you can
> always do
>begin;
>\i file
>end;
> It's only pg_restore that you really need it for. Dropping the psql
> part of the patch might give us a little more maneuvering room as far
> as the switch name goes.
>
>
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 particula
Simon Riggs <[EMAIL PROTECTED]> writes:
> The following patches add a -N option to psql and pgrestore.
-N seems an entirely random name for the switch ... can't we do better?
I see that -t, -T, -s, -S, -x and -X are all taken, which lets out the
obvious choices ... but I'd rather have no single-le
19 matches
Mail list logo
