什么是PostgreSQL等效于SQL Server NVARCHAR？

如果我在Microsoft SQL Server数据库中有NVARCHAR(或NTEXT)数据类型的字段,那么PostgreSQL数据库中的等效数据类型是什么？

我非常确定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代表的类似问题的回复:

如果您已正确安装PostgreSQL,我们所有的TEXT数据类型都具有多字节功能.
这包括:TEXT(推荐)VARCHAR CHAR

它是varchar和text,假设您的数据库采用UNICODE编码.如果您的数据库采用非UNICODE编码,则没有特殊的数据类型可以为您提供unicode字符串 - 您可以将其存储为bytea流,但这不是字符串.

标准TEXT数据类型非常适合它.

简短答案：没有与SQL Server NVARCHAR等效的PostgreSQL。

不同数据库上的NVARCHAR（N）类型不相等。该标准允许选择字符排序规则和编码/字符集。在处理unicode时，PostgreSQL和SQLServer属于不同的阵营，不存在对等关系。

这些不同

长度语义

可表示的内容

排序

填充语义

因此，将数据从一个数据库系统（或编码/字符集）移动到另一个数据库系统可能会导致截断/内容丢失。

具体地说，PostgreSQL（9.1）字符类型和SQL Server NVARCHAR之间没有等效项。

您可以将数据迁移到PostgreSQL二进制类型，但随后将失去文本查询功能。

（除非PostgreSQL开始支持基于UTF-16的Unicode字符集）

1）长度语义

根据数据库和编码，对N的解释不同（字符，字节，2 * N =字节）。

Microsoft SQL Server使用UCS2编码，并将VARCHAR长度解释为UCS-2点，即length * 2 =字节长度（https://docs.microsoft.com/zh-cn/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个字节（请参阅例如 http://www.oracletutorial.com/oracle-basics/oracle-nvarchar2/ ，其中明确指出NVARCHAR2（50）列可能占用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）。

2）无法代表的内容

基于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）处理来自企业/操作系统的数据时，UTF-16通常是一个杀手标准。请注意，JavaScript JSON编码特别注意能够表示这些字符（https://tools.ietf.org/html/rfc8259#page-10）。

（2）和（3）与迁移查询更相关，但与数据迁移无关。

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

4）填充语义

填充语义在数据库esp上有所不同。将VARCHAR与CHAR内容进行比较时。