Есть база SQL Server и соответствующая ей в PostgreSQL.
Пытаюсь скопироваь данные, использя приложение c#, приходится делать некоторые преобразования.

Вопрос: как можно, прочитав поля типа hierarchyid записать их в поле ltree в PostgreSQL?

ОКТОГЕНРолг ХупинЕсть база SQL Server и соответствующая ей в PostgreSQL.
Пытаюсь скопироваь данные, использя приложение c#, приходится делать некоторые преобразования.

Вопрос: как можно, прочитав поля типа hierarchyid записать их в поле ltree в PostgreSQL?
Написать функцию преобразования из hierarchyid в текст, соответствующий преобразованию
ltree2text(ltree) для postgrtesql.
А дальше тупо загнать это в postgrtesql с помощью text2ltree(text).

Да, в приложении я получаю hierarchyid, вопрос в том, как из hierarchyid получить подходящее значение для вставки в ltree.

Скажем, я получаю из SQL Server путь в виде строки
/
/1/
/2/
/2/1/
/2/2/
...

как преобразовать эти строки в строки, подходящие для ltree, чтобы дерево сохранилось в правильном виде?

MelkijДля показанных примеров данных - спилить по краям / и заменить остальные / на .
Если там только цифры - то этого будет достаточно. ltree ограничивает пути цифрами, буквами (в зависимости от локали базы) и не более 256 байт.


как быть с корнем? что вместо '/'?

там цифры, точнее числа, букв нет, но может быть другое, по-моему:
при вставке в существующе дерево могут быть узлы типа



/
/1/
/2/
/2/1/
/2/1.1/
/2/1.1.1/
/2/1.1/
/2/2/

MelkijРолг Хупин,

а зачем как-то на уровне данных отмечать корень? ltree - целиком materialized path, где в нём корень очевидно без какой-то явной маркировки.

Точки в элементах структуру дерева гарантированно поломают. ltree считает за разделители именно точки и по-моему это никак не меняется.

так в SQL Server сделано, рут есть в данных
0x
, и функция есть, возвращающая рут.

Как можно разрулить с таким деревом в SQL Server, чтобы задвинуть его в PGSQL?

empid emp hid path
------ -------- ----------------- -----------------------
1 A 0x /
2 | B 0x58 /1/
4 | D 0x62C0 /1.1/
6 | F 0x6316 /1.1.1/
8 | H 0x6318B0 /1.1.1.1/
9 | | I 0x6318B580 /1.1.1.1/1/
11 | | K 0x6318B62C /1.1.1.1/1.1/
13 | | L 0x6318B63160 /1.1.1.1/1.1.1/
15 | | N 0x6318B6318B /1.1.1.1/1.1.1.1/
17 | | P 0x6318B6318C58 /1.1.1.1/1.1.1.1.1/
19 | | E 0x6318B6318C62C0 /1.1.1.1/1.1.1.1.1.1/
21 | | T 0x6318B6318C6316 /1.1.1.1/1.1.1.1.1.1.1/
20 | | S 0x6318B6318C6340 /1.1.1.1/1.1.1.1.1.2/
18 | | Q 0x6318B6318C68 /1.1.1.1/1.1.1.1.2/
16 | | O 0x6318B6318D /1.1.1.1/1.1.1.2/

MelkijРолг Хупин,

Что-то не похож на рут, а скорее на hex значение внутреннего формата хранения дерева, совершенно явные закономерности.
Не вижу необходимости что-то с этим делать. Ну выводят в этом ms sql зачем-то ограничители по краям и фиг с ними. Или вам необходимо формат сохранить?

Если у вас в узлах данных используются точки - с этим сложнее. Или менять данные или не использовать ltree, а делать своё дерево

Почему не похож?
0x - самый рут, 0

Мне хотелось бы, чтобы иерархия сохранилась.
А это

13 | | L 0x6318B63160 /1.1.1.1/1.1.1/

hex 0x6318B63160 - то, что сидит в поле таблицы, а это
/1.1.1.1/1.1.1/

чисто для наглядности визуализация через функцию типа hierarchyid
hid.ToString()

Но это - результат обработки hex значения, там SQL Server делает хитрые пляски с байтами при вставке между существующими узлами

Но в моем случае я бы читал именно строковое представление, как вы и писали выше, искажал бы его, как нужно (если можно) и писал в PGSQL таблицу

Вопрос в том, всегда ли можно

Да, я проверил на двух больших базах, чисел с точками нет типа таких
/
/1/
/2/
/2/1/
/2/1.1/
/2/1.1.1/
/2/1.1/
/2/2/

так что попробую вашим советом для эксперимента воспользоваться