Read extension script files in text not binary mode.

This change affects only Windows, where it should cause DOS-style
newlines (\r\n) to be converted to plain \n during script loading.
This eliminates one potential discrepancy in the behavior of
extension script files between Windows and non-Windows.  While
there's a small chance that this might cause undesirable behavior
changes for some extensions, it can also be argued that this may
remove behavioral surprises for others.  An example is that in
the buildfarm, we are getting different results for the tests
added by commit 774171c4f depending on whether our git tree has
been checked out with Unix or DOS newlines.

The choice to use binary mode goes all the way back to our invention
of extensions in commit d9572c4e3.  However, I suspect it was not
thought through carefully but was just a side-effect of the ready
availability of an almost-suitable function read_binary_file().
On balance, changing to text mode seems like a better answer than
other ways in which we might fix the inconsistent test results.

Discussion: https://postgr.es/m/2480333.1729784872@sss.pgh.pa.us

diff --git a/src/backend/commands/extension.c b/src/backend/commands/extension.c
index 86ea9cd9da768b9e36c75f03971c42600ced597d..ec71761377c2d1826525fbeaf5630040717177de 100644 (file)
--- a/src/backend/commands/extension.c
+++ b/src/backend/commands/extension.c
@@ -3639,7 +3639,7 @@ read_whole_file(const char *filename, int *length)
                 errmsg("file \"%s\" is too large", filename)));
    bytes_to_read = (size_t) fst.st_size;
 
-   if ((file = AllocateFile(filename, PG_BINARY_R)) == NULL)
+   if ((file = AllocateFile(filename, "r")) == NULL)
        ereport(ERROR,
                (errcode_for_file_access(),
                 errmsg("could not open file \"%s\" for reading: %m",