Здравствуйте. Мне потребовалось в 1с добавить внешний источник из PostgreSQL но в таблицах используется тип uuid, который в 1с я не могу ни прочитать ни записать. Если в 1с я указывают тип "Строка", то в форме списка он мне показывает значения как 53 67 A7 8 и зайти элементы не дает с ошибкой типа:

Ошибка преобразования данных XDTO:
НачалоСвойства: val    Форма: Элемент    Тип: {http://www.w3.org/2001/XMLSchema}anyType
по причине:
Ошибка преобразования данных XDTO:
Значение: 53 67 A7 8    Тип: {http://v8.1c.ru/8.1/data/core}UUID
по причине:
Ошибка отображения типов:
Отображение лексического значения '53 67 A7 8' в значение типа 'УникальныйИдентификатор'

Если в 1с я указываю тип УникальныйИдентификатор, то в списке пусто, но новый элемент даст создать (выдаёт ошибку но в базе появляется)

Я подозреваю что он пытается преобразовать значение в ::bytea , хотя на самом деле надо ::uuid

Как быть? поиск ничего толком не дал

(0) Используй ADO и в запросе используй какой-нить местный convert или cast.

Смысл как раз во внешнем источнике, так как по таблицам нужны сложные отчеты и т.д., а не так, чтобы на каждую таблицу свою обработку рисовать.. хотя может до этого и дойдёт если не найдётся решение

(2) Пускай тогда тебе вьювку нарисуют)

Может и выход из положения но пока во вьюхе cast(... as varchar(36)) не даёт сделать... Хотя в обычном селекте нормально выбирает и показывает тип

С помощью views у меня получилось, но план показывает что не используются индексы, что не есть хорошо((

(0)
если я правильно понял вопрос,
может 1С тип ДвоичныеДанные?

(6)+
или Число 38. как-то так мне помогло.

В общем проблема решена следующими костылями:

Создание view

CREATE OR REPLACE VIEW public.wusers AS
SELECT manager_wusers.id::character varying(36) AS id,
    manager_wusers.login,
    manager_wusers.password,
    manager_wusers.full_name
   FROM main_wusers;

И если таблицу придётся изменять, то нужно еще добавить правило (и вручную следить чтобы id был uuid, т.к. теперь можно ввести любую строку и база будет ругаться матом)

CREATE RULE _INSERT AS
    ON INSERT TO wusers DO INSTEAD  INSERT INTO main_wusers (id, login, password, full_name)
  VALUES (new.id::uuid, new.login, new.password, new.full_name)
  RETURNING main_wusers.id::character varying(36) AS id,
    manager_wusers.login,
    manager_wusers.password,
    manager_wusers.full_name;


Это самая простая таблица которую нужно было внедрить, а их еще штук 30 с немалым количеством полей, так что теперь работы у меня выше крыши)))

PS: На этой таблице почему-то не работают индексы. Может на нормальных таблицах больших объёмах всё будет норм, ну или добавлять индексы к вьюхам как-то вручную
PSS: Главное не забывать страдать.

Жесть конечно как добавилось, извините если что)

(5) Есть еще вроде индексированные вьюхи.

+(10) Т.е. копнуть поглубже постгри   и сделать на физику витрины в виде вьюх , табличных функций или чего там еще .

Ну я в принципе этот вариант и описал, осталось решить проблему с индексами, не используя материализованных вьюх, а как всё работает. Думаю первое время потерпят тормоза если что

(0) для обратной задачи (прочитать uuid, сохраненные 1с как bytea) у меня есть вот такой костыль

может, тебе сделать в обратную сторону, но на стороне 1с?

кмк, раз недоработка на стороне 1с - то и костыль туда вставлять, а не в нормально работающую систему. мало ли, когда-нибудь эту особенность починят, и тогда останется один костыль убрать, а не кучу вьюх



CREATE OR REPLACE FUNCTION bytea2guid (bytea) RETURNS UUID AS
$$
DECLARE
  bin ALIAS FOR $1;
  hex TEXT;
  guid UUID;
BEGIN
  SELECT SUBSTRING(bin::text, 3) INTO hex;
  guid := SUBSTRING(hex, 25, 8) || '-' ||
          SUBSTRING(hex, 21, 4) || '-' ||
          SUBSTRING(hex, 17, 4) || '-' ||
          SUBSTRING(hex, 1, 4) || '-' ||
          SUBSTRING(hex, 5, 12);
  RETURN guid;
END;

$$
LANGUAGE plpgsql;