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

Re: Single-Transaction Utility options

From: Simon Riggs <simon(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-patches(at)postgresql(dot)org
Subject: Re: Single-Transaction Utility options
Date: 2005-12-16 20:49:51
Message-ID: 1134766191.2964.65.camel@localhost.localdomain (view raw or flat)
Thread:
Lists: pgsql-patches
On Fri, 2005-12-16 at 13:59 -0500, Tom Lane wrote:
> Simon Riggs <simon(at)2ndquadrant(dot)com> 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-letter abbreviation at
> all than one that has zero relationship to the function of the switch.

Almost. Stands for traNsaction....

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

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

Of course, you're right... and that is all the patch does in fact.

It seemed easier to do -1 than the SQL above, especially when doing it
from a single command line. But the main reason was to make all the
utilities work the same, if possible. Having different options on each
utility makes it easier to make mistakes, so I'd rather have the same
option everywhere that it could apply. I couldn't see any reason not to
do it, either.

Best Regards, Simon Riggs




In response to

Responses

pgsql-patches by date

Next:From: Simon RiggsDate: 2005-12-16 20:53:36
Subject: Re: Single-Transaction Utility options
Previous:From: Tom LaneDate: 2005-12-16 19:51:55
Subject: Re: Solaris cc compiler on amd: PostgreSQL does not have native spinlock support on this platform

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