On Thursday 12 February 2009 11:50:26 Joshua D. Drake wrote: > On Thu, 2009-02-12 at 11:47 -0500, Andrew Dunstan wrote: > > Joshua D. Drake wrote: > > > On Thu, 2009-02-12 at 11:32 -0500, Tom Lane wrote: > > >> Andrew Dunstan <and...@dunslane.net> writes: > > >>> The implementation is actually different across platforms: on Windows > > >>> the workers are genuine threads, while elsewhere they are forked > > >>> children in the same fashion as the backend (non-EXEC_BACKEND case). > > >>> In either case, the program will use up to NUM concurrent connections > > >>> to the server. > > >> > > >> How about calling it --num-connections or something like that? I > > >> agree with Peter that "thread" is not the best terminology on > > >> platforms where there is no threading involved. > > > > > > --num-workers or --num-connections would both work. > > > > *shrug* whatever. What should the short option be (if any?). -n is > > taken, so -N ? > > Works for me. >
yikes... -n and -N have specific meaning to pg_dump, I think keeping consistency with that in pg_restore would be a bonus. (I still see people get confused because -d work differently between those two apps) Possibly -w might work, which could expand to --workers, which glosses over the thread/process difference, is also be available for pg_dump, and has existing mindshare with autovacuum workers. not having a short option seems ok to me too, but I really think -N is a bad idea. -- Robert Treat Conjecture: http://www.xzilla.net Consulting: http://www.omniti.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
