From 927d61eeff78363ea3938c818d07e511ebaf75cf Mon Sep 17 00:00:00 2001 From: Bruce Momjian Date: Sun, 10 Jun 2012 15:20:04 -0400 Subject: Run pgindent on 9.2 source tree in preparation for first 9.3 commit-fest. --- src/bin/psql/copy.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) (limited to 'src/bin/psql/copy.c') diff --git a/src/bin/psql/copy.c b/src/bin/psql/copy.c index a1dea9502c2..22fcc5975e5 100644 --- a/src/bin/psql/copy.c +++ b/src/bin/psql/copy.c @@ -394,7 +394,7 @@ handleCopyOut(PGconn *conn, FILE *copystream) /* * Check command status and return to normal libpq state. After a * client-side error, the server will remain ready to deliver data. The - * cleanest thing is to fully drain and discard that data. If the + * cleanest thing is to fully drain and discard that data. If the * client-side error happened early in a large file, this takes a long * time. Instead, take advantage of the fact that PQexec() will silently * end any ongoing PGRES_COPY_OUT state. This does cause us to lose the @@ -405,7 +405,7 @@ handleCopyOut(PGconn *conn, FILE *copystream) * We must not ever return with the status still PGRES_COPY_OUT. Our * caller is unable to distinguish that situation from reaching the next * COPY in a command string that happened to contain two consecutive COPY - * TO STDOUT commands. We trust that no condition can make PQexec() fail + * TO STDOUT commands. We trust that no condition can make PQexec() fail * indefinitely while retaining status PGRES_COPY_OUT. */ while (res = PQgetResult(conn), PQresultStatus(res) == PGRES_COPY_OUT) @@ -584,6 +584,7 @@ handleCopyIn(PGconn *conn, FILE *copystream, bool isbinary) OK = false; copyin_cleanup: + /* * Check command status and return to normal libpq state * -- cgit v1.2.3