Report the database locale on PostgreSQL 15, and skip what Windows cannot do

Three things, all turned up by CI.

get_ctypes.sql only existed from the 16_plus bucket down, so a PostgreSQL
15 server fell back to the default template and reported the server's own
lc_collate and lc_ctype settings rather than anything about the database,
which is exactly the bug this is meant to fix. datlocprovider and
daticulocale both arrived in 15, and 15 is also where a database first
stopped necessarily collating according to datcollate and datctype, so
the template moves down to the 15_plus bucket unchanged rather than being
duplicated.

The two libc scenarios deliberately set LC_COLLATE and LC_CTYPE to
different values, since that is what proves which of the two columns the
query reported. Windows builds accept the CREATE DATABASE but then refuse
to open the result, so those two scenarios now skip with the server's own
explanation when that is what comes back, and continue to fail on
anything else.

The builtin scenario no longer skips when template0 uses 'C' or 'POSIX'.
That guard belongs to the libc scenarios, which need a template locale
distinguishable from the defaults; the builtin scenario distinguishes
against the 'C.UTF-8' it creates the database with, and 'C' and 'POSIX'
are both perfectly distinguishable from that, so skipping them only lost
the scenario on the servers most likely to have a default template0.

Author: dpage

…tes/databases/sql/16_plus/get_ctypes.sql …tes/databases/sql/15_plus/get_ctypes.sqlweb/pgadmin/browser/server_groups/servers/databases/templates/databases/sql/16_plus/get_ctypes.sql renamed to web/pgadmin/browser/server_groups/servers/databases/templates/databases/sql/15_plus/get_ctypes.sql web/pgadmin/browser/server_groups/servers/databases/templates/databases/sql/16_plus/get_ctypes.sql renamed to web/pgadmin/browser/server_groups/servers/databases/templates/databases/sql/15_plus/get_ctypes.sql

@@ -1,3 +1,6 @@
+{# datlocprovider and daticulocale both arrived in PostgreSQL 15, which is
+   also where a database first stopped necessarily collating according to
+   datcollate and datctype, so this bucket starts there. #}
 SELECT daticulocale AS cname FROM pg_catalog.pg_database
 WHERE datname = current_database() AND datlocprovider = 'i'
 UNION

web/pgadmin/browser/server_groups/servers/databases/tests/test_db_get_ctypes.py

@@ -22,6 +22,7 @@
 
 import uuid
 
+import psycopg
 from flask import render_template
 
 from pgadmin.utils.route import BaseTestGenerator
@@ -105,7 +106,18 @@ def runTest(self):
                 else (self.template_collate, 'C')
             self._create_database(
                 "LC_COLLATE '%s' LC_CTYPE '%s'" % (collate, ctype))
-            self.assertIn(self.template_collate, self._reported_locales())
+            try:
+                reported = self._reported_locales()
+            except psycopg.OperationalError as exc:
+                # Windows builds accept the CREATE DATABASE but refuse to
+                # open a database whose collation and character type differ,
+                # so the pair that proves which of the two columns was read
+                # cannot be exercised there.
+                if 'not supported on this platform' not in str(exc):
+                    raise
+                self.skipTest('This server will not open a database whose '
+                              'collate and ctype differ: %s' % exc)
+            self.assertIn(self.template_collate, reported)
             return
 
         if self.provider == 'builtin':
@@ -121,7 +133,12 @@ def runTest(self):
                               "the only one a UTF-8 builtin database can "
                               "use, so a distinguishable one cannot be "
                               "created here.")
-            self._skip_unless_distinct_template_locale()
+            # Unlike the libc scenarios, nothing here needs a template
+            # locale that differs from the defaults: 'C' and 'POSIX' are
+            # both perfectly distinguishable from the 'C.UTF-8' the builtin
+            # database is created with, and skipping them would lose the
+            # scenario on exactly the servers most likely to have a default
+            # template0.
             self._create_database("LOCALE_PROVIDER builtin "
                                   "BUILTIN_LOCALE 'C.UTF-8' ENCODING UTF8")