Win32 fix for pg_dumpall

Started by Bruce Momjianalmost 22 years ago6 messagespatches
Jump to latest
#1Bruce Momjian
bruce@momjian.us

Here is fix for Win32 pg_dumpall that Claudio helped with.

Attached and applied.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Attachments:

/bjm/difftext/plainDownload+17-3
#2Andrew Dunstan
andrew@dunslane.net
In reply to: Bruce Momjian (#1)
Re: Win32 fix for pg_dumpall

Bruce Momjian wrote:

/*
+ 			 *	Sometime the child returns "\r\n", which doesn't match
+ 			 *	our version string.  The backend uses
+ 			 *	setvbuf(stdout, NULL, _IONBF, 0), but pg_dump doesn't
+ 			 *	so we have to fix it here.
+ 			 */
+ 			if (strlen(line) >= 2 &&
+ 				line[strlen(line)-2] == '\r' &&
+ 				line[strlen(line)-1] == '\n')
+ 			{
+ 				line[strlen(line)-2] == '\n';
+ 				line[strlen(line)-1] == '\0';
+ 			}
+ 
+ 			/*

I do not see how the comment relates at all to the code following it -
buffer mode and line end mode are two different things. Also, the
repeated calls to strlen(line) are horribly inefficient - it should be
called once and stashed in an int (I once made an order of magnitude
speedup in a program by correcting a piece of someone else's code that
looked like this: for (i = 0; i <= strlen(s); i++) where s was an
invariant very long string)

cheers

andrew

#3Bruce Momjian
bruce@momjian.us
In reply to: Andrew Dunstan (#2)
Re: Win32 fix for pg_dumpall

Andrew Dunstan wrote:

Bruce Momjian wrote:

/*
+ 			 *	Sometime the child returns "\r\n", which doesn't match
+ 			 *	our version string.  The backend uses
+ 			 *	setvbuf(stdout, NULL, _IONBF, 0), but pg_dump doesn't
+ 			 *	so we have to fix it here.
+ 			 */
+ 			if (strlen(line) >= 2 &&
+ 				line[strlen(line)-2] == '\r' &&
+ 				line[strlen(line)-1] == '\n')
+ 			{
+ 				line[strlen(line)-2] == '\n';
+ 				line[strlen(line)-1] == '\0';
+ 			}
+ 
+ 			/*

I do not see how the comment relates at all to the code following it -
buffer mode and line end mode are two different things. Also, the

Yea, you would _think_ they are unrelated on Win32, but they aren't.
:-)

Turns out when you do that call in the backend, all EOLs become \n and
not \r\n. This is what Claudio found. Let me document the strangeness
of this more clearly.

repeated calls to strlen(line) are horribly inefficient - it should be
called once and stashed in an int (I once made an order of magnitude
speedup in a program by correcting a piece of someone else's code that
looked like this: for (i = 0; i <= strlen(s); i++) where s was an
invariant very long string)

OK, I will clean that up too, but after beta1.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073
#4Bruce Momjian
bruce@momjian.us
In reply to: Andrew Dunstan (#2)
Re: Win32 fix for pg_dumpall

OK, I have cleaned up this code and clarified the comment. Attached and
applied.

---------------------------------------------------------------------------

Andrew Dunstan wrote:

Bruce Momjian wrote:

/*
+ 			 *	Sometime the child returns "\r\n", which doesn't match
+ 			 *	our version string.  The backend uses
+ 			 *	setvbuf(stdout, NULL, _IONBF, 0), but pg_dump doesn't
+ 			 *	so we have to fix it here.
+ 			 */
+ 			if (strlen(line) >= 2 &&
+ 				line[strlen(line)-2] == '\r' &&
+ 				line[strlen(line)-1] == '\n')
+ 			{
+ 				line[strlen(line)-2] == '\n';
+ 				line[strlen(line)-1] == '\0';
+ 			}
+ 
+ 			/*

I do not see how the comment relates at all to the code following it -
buffer mode and line end mode are two different things. Also, the
repeated calls to strlen(line) are horribly inefficient - it should be
called once and stashed in an int (I once made an order of magnitude
speedup in a program by correcting a piece of someone else's code that
looked like this: for (i = 0; i <= strlen(s); i++) where s was an
invariant very long string)

cheers

andrew

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Attachments:

/bjm/difftext/plainDownload+22-21
#5Tom Lane
tgl@sss.pgh.pa.us
In reply to: Bruce Momjian (#4)
Re: Win32 fix for pg_dumpall

Bruce Momjian <pgman@candle.pha.pa.us> writes:

/*
* We emulate fgets() behaviour. So if there is no newline
* at the end, we add one...
*/
! if (line[len-1] != '\n')
strcat(line,"\n");
}

This is untrustworthy if len is zero. Perhaps

if (len == 0 || line[len-1] != '\n')
strcat(line,"\n");

regards, tom lane

#6Bruce Momjian
bruce@momjian.us
In reply to: Tom Lane (#5)
Re: Win32 fix for pg_dumpall

Tom Lane wrote:

Bruce Momjian <pgman@candle.pha.pa.us> writes:

/*
* We emulate fgets() behaviour. So if there is no newline
* at the end, we add one...
*/
! if (line[len-1] != '\n')
strcat(line,"\n");
}

This is untrustworthy if len is zero. Perhaps

if (len == 0 || line[len-1] != '\n')
strcat(line,"\n");

Agreed, fixed.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073