So we seem to be out of the woods in terms of 0ba06e0bf breaking the
regression tests, but I'm not very happy about the whole thing, because
that patch wasn't supposed to change the behavior of open/fopen in any
way other than allowing concurrent file access. Obviously, it did.
After looking at src/port/open.c a bit, it seems like the problem is
that our fopen() requires a nonstandard "t" option to select text mode.
I'd always supposed that you got binary mode with "b" and text mode
otherwise; is there some third possibility on Windows?
Anyway, I'm inclined to propose that we ought to do something like
the attached in HEAD and v11 in order to reduce the risk that there
are other unexpected behavioral changes. This should also let us
revert 0ba06e0bf's change in initdb.c.
I wonder whether pgwin32_open() also ought to enforce that either
O_BINARY or O_TEXT mode gets selected.
regards, tom lane
diff --git a/src/port/open.c b/src/port/open.c
index a3ad946..85ab06e 100644
--- a/src/port/open.c
+++ b/src/port/open.c
@@ -154,7 +154,7 @@ pgwin32_fopen(const char *fileName, const char *mode)
if (strchr(mode, 'b'))
openmode |= O_BINARY;
- if (strchr(mode, 't'))
+ else
openmode |= O_TEXT;
fd = pgwin32_open(fileName, openmode);
diff --git a/src/bin/initdb/initdb.c b/src/bin/initdb/initdb.c
index b53d6eb..cb8c745 100644
--- a/src/bin/initdb/initdb.c
+++ b/src/bin/initdb/initdb.c
@@ -491,15 +491,7 @@ readfile(const char *path)
char *buffer;
int c;
-#ifdef WIN32
- /*
- * On Windows, we have to open the file in text mode so that carriage
- * returns are stripped.
- */
- if ((infile = fopen(path, "rt")) == NULL)
-#else
if ((infile = fopen(path, "r")) == NULL)
-#endif
{
fprintf(stderr, _("%s: could not open file \"%s\" for reading: %s\n"),
progname, path, strerror(errno));
