如果我在Microsoft SQL Server数据库中有NVARCHAR（或NTEXT）数据类型的字段，那么PostgreSQL数据库中的等效数据类型是什么？
答案 0 :(得分：32)
我很确定postgres varchar与Oracle / Sybase / MSSQL nvarchar相同，即使它在手册中没有明确说明：
http://www.postgresql.org/docs/7.4/static/datatype-character.html
编码转换函数在这里：
http://www.postgresql.org/docs/current/static/functions-string.html http://www.postgresql.org/docs/current/static/functions-string.html#CONVERSION-NAMES
示例：
create table
nvctest (
utf8fld varchar(12)
);
insert into nvctest
select convert('PostgreSQL' using ascii_to_utf_8);
select * from nvctest;
此外，对于来自Postgresql代表的类似问题有this response：
我们所有的TEXT数据类型都是 多字节能力，只要你有 正确安装了PostgreSQL 这包括：TEXT（推荐） VARCHAR CHAR
答案 1 :(得分：10)
它是 varchar 和 text ，假设您的数据库采用UNICODE编码。如果您的数据库采用非UNICODE编码，则没有特殊的数据类型可以为您提供unicode字符串 - 您可以将其存储为bytea流，但这不是字符串。
答案 2 :(得分：7)
标准TEXT数据类型非常适合它。
答案 3 :(得分：3)
简短答案：没有与SQL Server NVARCHAR等效的PostgreSQL。
不同数据库上NVARCHAR（N）的类型不相同。 该标准允许选择字符排序规则和编码/字符集。在处理unicode时，PostgreSQL和SQLServer属于不同的阵营，不存在对等关系。
这些有所不同
因此，将数据从一个数据库系统（或编码/字符集）移动到另一个数据库系统可能会导致截断/内容丢失。
特别是，在PostgreSQL（9.1）字符类型和SQL Server NVARCHAR之间没有等效项。
您可以将数据迁移到PostgreSQL二进制类型，但随后将失去文本查询功能。
（除非PostgreSQL开始支持基于UTF-16的unicode字符集）
根据数据库和编码，对N的解释不同（字符，字节，2 * N =字节）。
Microsoft SQL Server使用UCS2编码，并将VARCHAR长度解释为UCS-2点，即length * 2 =字节长度（https://docs.microsoft.com/en-us/sql/t-sql/data-types/nchar-and-nvarchar-transact-sql?view=sql-server-2017）：
它们的NVARCHAR（1）可以存储1个UCS2字符（UCS2的2个字节）。
Oracle UTF编码具有相同的语义（和内部CESU-8存储）。
Postgres 9.1仅具有Unicode UTF-8字符集（https://www.postgresql.org/docs/9.1/multibyte.html），该字符集与 Oracle（采用AL32UTF8或AL16UTF16编码）可以存储1个完整的UCS32代码点。最多可能有4个字节（例如，请参见 明确声明NVARCHAR2（50）列的http://www.oracletutorial.com/oracle-basics/oracle-nvarchar2/可能最多占用200个字节。
在处理基本多语言平面之外的字符时，这种区别变得很明显，这些字符在utf8 ucs32（go，char，char32_t，PostgreSQL）中被视为一个“ char单位”，但在UTF-16中被表示为代理对，该对被视为两个单位（Java，Javascript，C＃，ABAP，wchar_t和SQLServer）。
例如 带有微笑眼睛的U + 1F60A微笑面将耗尽SQL Server NVARCHAR（2）中的所有空间。 但是在PostgreSQL中只有一个字符单元。
古典企业级数据库将提供至少一种带有UTF-16之类的语义的选择（SAP HANA（CESU-8），具有排序规则的DB 2，SQL Anywhere（CESU8BIN）等）。 例如。 Oracle还提供了他们误导性的UTF-8排序规则，实际上就是CESU-8。 它具有相同的长度语义，可表示的内容与UTF-16（= Microsoft SQL Server）相同，是基于UTF-16的企业系统（例如SAP R / 3）或Java应用程序服务器下使用的合适归类。
请注意，即使使用可变长度的unicode编码，某些数据库仍可能将NVARCHAR（N）解释为字节限制的长度（示例SAP IQ）。
基于UTF-16 / CESU-8的系统可以代表一半代理对，而 基于UTF-8 / UTF-32的系统不能。 此内容在此字符集中无法表示，但在基于UTF-16的企业系统中经常出现。 （例如Windows路径名可能包含此类非utf-8可表示的字符，请参见例如https://github.com/rust-lang/rust/issues/12056）。 因此，UTF-16是UTF-8 / UTF-16的“超集”，当基于这种编码（SAP，Windows，Java，JavaScript）处理来自企业/操作系统的数据时，它通常是一个杀手标准。请注意，JavaScript JSON编码特别注意能够表示这些字符（https://tools.ietf.org/html/rfc8259#page-10）。
（2）和（3）在迁移查询时更为相关，但与数据迁移无关。
请注意，CESU-8 / UTF-16的二进制排序顺序不同于UTF-8 / UTF-32。
UTF-16 / CESU-8 / Java / JavaScript / ABAP排序顺序：
U+0041 LATIN CAPITAL LETTER A
U+1F60A SMILING FACE WITH SMILING EYES
U+FB03 LATIN SMALL LIGATURE ffi
UTF-8 / UCS-32（go）排序顺序：
U+0041 LATIN CAPITAL LETTER A
U+FB03 LATIN SMALL LIGATURE ffi
U+1F60A SMILING FACE WITH SMILING EYES
在数据库上，填充语义有所不同。将VARCHAR与CHAR内容进行比较时。