[注意]在PostgreSQL 8.1版本中，(UTF8)UNICODE编码在Windows平台上是完全支持的。这个条目是仅仅针对8.0版本而言的。
对于PostgreSQL而言，“UNICODE"等价于"UTF8”。Windows平台上的PostgreSQL 8.0版本对UTF8的支持是不完整的，因此不能使用。安装程序将允许你选择任何PostgreSQL和Windows同时支持的编码。
在pgsql-hackers邮件列表中，Aleksander Kmetec详细阐述了Unicode问题：
因为Postgres依赖于操作系统的一些字符串处理函数，所以操作系统需要支持数据库使用的编码。很不幸，Windows并不支持PG的某些服务端编码。
如果前面说的你不太明白，这里有一个简短的实际例子：对于一个UNICODE(即UTF8)数据库，你应当在运行initdb时使用一个兼容的locale，对我而言也就是：“sl_SI.utf8”(Linux)或"Slovenian_Slovenia.65001" (Windows)。
对于我们中国人来说则是：“zh_CN.utf8”(Linux)或"Chinese_People’s Republic of China.65001"(Windows)。
虽然Windows下号称utf8的代码页(codepage)是65001，但实际上这并不是一个真正有效的代码页。
“65000(UTF-7)和65001(UTF-8)只是伪代码页，它们并没有相应的NLS(本地语言支持)文件。这两个代码页的数字只能在调用WideCharToMultiByte()和MultiByteToWideChar() API时一起使用。”
这就意味着 UPPER(), LOWER(), ORDER BY 在UNICODE数据库上不能正确工作，甚至不能在运行initdb时使用65001代码页。虽然小小的改变一下initdb可以允许我将 LC_COLLATE设为"Slovenian_Slovenia.65001"，但是排序的结果仍然是一团糟。原因在前面的引用中已经解释了。
经过检查，我得到了Windows下的PG实际支持但并未公开的编码列表：
* UTF8
* EUC_CN
* EUC_TW
* LATIN6 (ISO 8859-10/ECMA 144)
* LATIN7 (ISO 8859-13)
* LATIN8 (ISO 8859-14)
* LATIN10 (ISO 8859-16/ASRO SR 14111)