Require ucrt if using MinGW.

Historically we tolerated the absence of various C runtime library
features for the benefit of the MinGW tool chain, because it used
ancient msvcrt.dll for a long period of time.  It now uses ucrt by
default (like Windows 10+, Visual Studio 2015+), and that's the only
configuration we're testing.

In practice, we effectively required ucrt already in PostgreSQL 17, when
commit 8d9a9f03 required _create_locale etc, first available in
msvcr120.dll (Visual Studio 2013, the last of the pre-ucrt series of
runtimes), and for MinGW users that practically meant ucrt because it
was difficult or impossible to use msvcr120.dll.  That may even not have
been the first such case, but old MinGW configurations had already
dropped off our testing radar so we weren't paying much attention.

This commit formalizes the requirement.  It also removes a couple of
obsolete comments that discussed msvcrt.dll limitations, and some tests
of !defined(_MSC_VER) to imply msvcrt.dll.  There are many more
anachronisms, but it'll take some time to figure out how to remove them
all.  APIs affected relate to locales, UTF-8, threads, large files and
more.

Thanks to Peter Eisentraut for the documentation change.  It's not
really necessary to talk about ucrt explicitly in such a short section,
since it's the default for MinGW-w64 and MSYS2.  It's enough to prune
references and broken links to much older tools.

Reviewed-by: Peter Eisentraut <peter@eisentraut.org>
Discussion: https://postgr.es/m/d9e7731c-ca1b-477c-9298-fa51e135574a%40eisentraut.org

doc/src/sgml/installation.sgml

@@ -3582,33 +3582,9 @@ xcrun --show-sdk-path
 
    <para>
     PostgreSQL for Windows can be built using MinGW, a Unix-like build
-    environment for Microsoft operating systems.
-    The MinGW build procedure uses the normal build system described in
-    this chapter.
-   </para>
-
-   <para>
-    MinGW, the Unix-like build tools, and MSYS, a collection
-    of Unix tools required to run shell scripts
-    like <command>configure</command>, can be downloaded
-    from <ulink url="http://www.mingw.org/"></ulink>.  Neither is
-    required to run the resulting binaries; they are needed only for
-    creating the binaries.
-   </para>
-
-   <para>
-     To build 64 bit binaries using MinGW, install the 64 bit tool set
-     from <ulink url="https://mingw-w64.org/"></ulink>, put its bin
-     directory in the <envar>PATH</envar>, and run
-     <command>configure</command> with the
-     <command>--host=x86_64-w64-mingw32</command> option.
-   </para>
-
-   <para>
-    After you have everything installed, it is suggested that you
-    run <application>psql</application>
-    under <command>CMD.EXE</command>, as the MSYS console has
-    buffering issues.
+    environment for Windows.  It is recommended to use the <ulink
+    url="https://www.msys2.org/">MSYS2</ulink> environment for this and also
+    to install any prerequisite packages.
    </para>
 
    <sect3 id="mingw-crash-dumps">
@@ -3838,35 +3814,9 @@ make: *** [postgres] Error 1
         <productname>Bison</productname> and <productname>Flex</productname> are
         required.  Only <productname>Bison</productname> versions 2.3 and later
         will work. <productname>Flex</productname> must be version 2.5.35 or later.
+        Binaries can be downloaded from <ulink
+        url="https://github.com/lexxmark/winflexbison"></ulink>.
        </para>
-
-       <para>
-        Both <productname>Bison</productname> and <productname>Flex</productname>
-        are included in the <productname>msys</productname> tool suite, available
-        from <ulink url="http://www.mingw.org/wiki/MSYS"></ulink> as part of the
-        <productname>MinGW</productname> compiler suite.
-       </para>
-
-       <para>
-        You will need to add the directory containing
-        <filename>flex.exe</filename> and <filename>bison.exe</filename> to the
-        PATH environment variable. In the case of MinGW, the directory is the
-        <filename>\msys\1.0\bin</filename> subdirectory of your MinGW
-        installation directory.
-       </para>
-
-       <note>
-        <para>
-          The Bison distribution from GnuWin32 appears to have a bug that
-          causes Bison to malfunction when installed in a directory with
-          spaces in the name, such as the default location on English
-          installations <filename>C:\Program Files\GnuWin32</filename>.
-          Consider installing into <filename>C:\GnuWin32</filename> or use the
-          NTFS short name path to GnuWin32 in your PATH environment setting
-          (e.g., <filename>C:\PROGRA~1\GnuWin32</filename>).
-         </para>
-       </note>
-
        </listitem>
       </varlistentry>
      </variablelist>

src/backend/utils/adt/pg_locale.c

@@ -1017,13 +1017,6 @@ cache_locale_time(void)
  * get ISO Locale name directly by using GetLocaleInfoEx() with LCType as
  * LOCALE_SNAME.
  *
- * MinGW headers declare _create_locale(), but msvcrt.dll lacks that symbol in
- * releases before Windows 8. IsoLocaleName() always fails in a MinGW-built
- * postgres.exe, so only Unix-style values of the lc_messages GUC can elicit
- * localized messages. In particular, every lc_messages setting that initdb
- * can select automatically will yield only C-locale messages. XXX This could
- * be fixed by running the fully-qualified locale name through a lookup table.
- *
  * This function returns a pointer to a static buffer bearing the converted
  * name or NULL if conversion fails.
  *
@@ -1031,8 +1024,6 @@ cache_locale_time(void)
  * [2] https://docs.microsoft.com/en-us/windows/win32/intl/locale-names
  */
 
-#if defined(_MSC_VER)
-
 /*
  * Callback function for EnumSystemLocalesEx() in get_iso_localename().
  *
@@ -1201,16 +1192,6 @@ IsoLocaleName(const char *winlocname)
 		return get_iso_localename(winlocname);
 }
 
-#else							/* !defined(_MSC_VER) */
-
-static char *
-IsoLocaleName(const char *winlocname)
-{
-	return NULL;				/* Not supported on MinGW */
-}
-
-#endif							/* defined(_MSC_VER) */
-
 #endif							/* WIN32 && LC_MESSAGES */