Что такое PostgreSQL эквивалентно SQL Server NVARCHAR?

Ответ 1

Я уверен, что 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:

Все наши TEXT-типы данных многобилетный, если у вас есть правильно установлен PostgreSQL.
Это включает в себя: ТЕКСТ (рекомендуется) VARCHAR CHAR

Ответ 2

Это varchar и текст, если ваша база данных находится в кодировке UNICODE. Если ваша база данных находится в кодировке, отличной от UNICODE, нет специального типа данных, который даст вам строку в Юникоде - вы можете сохранить его как поток bytea, но это не будет строка.

Ответ 3

Стандартный тип данных TEXT отлично подходит для него.

Ответ 4

Краткий ответ: PostgreSQL, эквивалентный SQL Server NVARCHAR, не существует.

Типы NVARCHAR (N) в разных базах данных не эквивалентны. Стандарт допускает широкий выбор сопоставлений символов и кодировок/наборов символов. При работе с юникодом PostgreSQL и SQLServer попадают в разные лагеря и эквивалентности не существует.

Они отличаются по

1. семантика длины
2. представимое содержание
3. Порядок сортировки
4. семантика заполнения

Таким образом, перемещение данных из одной системы БД (или кодировки/набора символов) в другую может привести к усечению/потере контента.

В частности, нет эквивалента между символьным типом PostgreSQL (9.1) и SQL Server NVARCHAR.

Вы можете перенести данные в двоичный тип PostgreSQL, но затем потеряете возможности текстовых запросов.

(Если только PostgreSQL не начнет поддерживать набор символов Unicode на основе UTF-16)

1) семантика длины

N интерпретируется по-разному (символы, байты, 2 * N = байты) в зависимости от базы данных и кодировки.

Microsoft SQL Server использует кодировку UCS2 с длиной VARCHAR, интерпретируемой как точки UCS-2, то есть длина * 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 (2 байта UCS2). 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), но представляются в виде суррогатных пар в UTF-16, которые считаются двумя единицами ( Java, Javascript, С#, ABAP, wchar_t, SQLServer).

например, U + 1F60A УЛЫБАЮЩЕЕ ЛИЦО С УЛЫБАЮЩИМИСЯ ГЛАЗАМИ будет использовать все пространство в SQL Server NVARCHAR (2). Но только один символьный блок в PostgreSQL.

Классические БД корпоративного уровня будут предлагать по крайней мере выбор с семантикой, подобной UTF-16 (SAP HANA (CESU-8), БД 2 с сопоставлением, SQL Anywhere (CESU8BIN),...) Например, Oracle также предлагает то, что они вводят в заблуждение, как UTF -8 Сличение, которое эффективно CESU-8. Он имеет ту же семантику длины, представимое содержимое, что и UTF-16 (= Microsoft SQL Server), и является подходящим сопоставлением, используемым в корпоративных системах на основе UTF-16 (например, SAP R/3) или на сервере приложений Java.

Обратите внимание, что некоторые базы данных могут по-прежнему интерпретировать NVARCHAR (N) как ограничение длины в байтах, даже с кодировкой Unicode переменной длины (пример 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). Обратите внимание, что 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) семантика заполнения

Семантика заполнения отличается в базах данных, особенно. при сравнении VARCHAR с содержанием CHAR.