The documentation is not very clear with respect to the relationship between the encoding / character set of the database and the ctype / codeset of the collation. All that it mentions are the following statements (all found on the 22.3. Character Set Support documentation page):
each database's character set must be compatible with the database's LC_CTYPE (character classification) and LC_COLLATE (string sort order) locale settings
On Windows, ..., UTF-8 encoding can be used with any locale.
Important: On most modern operating systems, PostgreSQL can determine which character set is implied by the LC_CTYPE setting, and it will enforce that only the matching database encoding is used. On older systems it is your responsibility to ensure that you use the encoding expected by the locale you have selected. A mistake in this area is likely to lead to strange behavior of locale-dependent operations such as sorting.
There is an implication here that the
LC_CTYPE value only has rules for the characters in its Character Set. A value of
1252 indicates an Extended ASCII Code Page for Windows Latin1. All of those characters can be encoded into UTF-8 (you current encoding), but that doesn't necessarily mean that locale-aware functions such as
initcap, etc will behave as expected when operating on characters that exist outside of the Code Page. This should be testable by running one of those functions on a character that is not in the Windows Latin1 / Code Page 1252 character set. For example, Latin Small Letter Nj U+01CC:
should capitalize to:
So, if (sorry, I don't have PostgreSQL at the moment to test with) the following;
SELECT upper('ǌ'), lower('Ǌ');
then it looks very positive that the "1252"
LC_CTYPE value is not adversely affecting anything. It would still be good to try a
SELECT with an
ORDER BY since sorting was mentioned a few times in the documentation as an area that would likely be affected if these values -- encoding and LC_CTYPE -- were in conflict.
You cannot change either
LC_CTYPE once a database has been created, so you could try creating a new database to see if you can get the desired settings, regardless of what the installer thinks you should have:
CREATE DATABASE my_db_name WITH
You might need to look in the pg_collation system catalog to see what is available.