From: | Martijn van Oosterhout <kleptog(at)svana(dot)org> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Status during copy [patch] |
Date: | 2003-05-18 13:20:33 |
Message-ID: | 20030518132033.GE10998@svana.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
The following (link to a) patch is a first attempt to add updates during a
\copy. This is so that one has some idea of progress. The output looks as
follows:
kleptog=# \copy website to /tmp/g
COPY OUT 0:00:00 28 lines completed.
kleptog=# \copy a from /tmp/h
ERROR: copy: line 186645, Invalid UNICODE character sequence found (0xe05f6c)
lost synchronization with server, resetting connection
kleptog=# \copy a from /tmp/i
COPY IN 0:00:42 100000 lines completed.
\.
http://svana.org/kleptog/pgsql/psql-copy.patch
File: src/bin/psql/copy.c +64 -3
The output is updated every 1000 rows. A total is listed at the end of the
copy. When there's an error, no summary is printed.
The output is sent to stderr, because it needs to be unbuffered and you
generally don't want the progress to be redirected to a file. However, if
stderr is redirected, should we just not print anything? What about
non-interactive? Should it be a command-line option?
Note it's not against current CVS since the anoncvs server is not working
for me (error below). However, the sources don't appear to have changed too
much.
cvs [update aborted]: connect to anoncvs.postgresql.org(64.49.215.9):2401
failed: Connection refused
Comments appreciated.
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> "the West won the world not by the superiority of its ideas or values or
> religion but rather by its superiority in applying organized violence.
> Westerners often forget this fact, non-Westerners never do."
> - Samuel P. Huntington
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Stark | 2003-05-18 13:24:06 | Re: Feature suggestions (long) |
Previous Message | Greg Stark | 2003-05-18 13:07:26 | Re: Text format protocol representation |