Беспорядочные разрывы строк портят исходный код при сбросе / восстановлении - PullRequest
Новая
       12

Беспорядочные разрывы строк портят исходный код при сбросе / восстановлении

1 голос
/ 11 ноября 2010

Чтобы быть кратким: процесс дампа / восстановления делает исходный код моих функций уродливым! Бог знает почему, но что-то добавляет дополнительные разрывы строк в мой красиво отформатированный исходный код таким образом, что меня действительно бесит (и затрудняет чтение моего кода). Небольшая иллюстрация того, что происходит после восстановления базы данных: 

CREATE OR REPLACE FUNCTION f_tr_std()
  RETURNS trigger AS
$BODY$







begin







  /* Standard trigger function */







  if ( tg_when <> 'BEFORE' ) then







    raise exception 'This must be a "before"-trigger only: "%"', tg_name;







  end if;















  if ( tg_level <> 'ROW' ) then







    raise exception 'This must be a row-level trigger: "%"', tg_name;







  end if;















end;







$BODY$
  LANGUAGE plpgsql VOLATILE
  COST 100;
ALTER FUNCTION f_tr_std() OWNER TO postgres;

Верхний и нижний колонтитулы сгенерированы pgAdmin. Остальное мой собственный код.

PG версия: 9.0.1 ОС: Windows XP

Содержимое bat-файла, которое я использую для дампа: 

@echo off
set curr_dir=%CD%
pg_dump --blobs --format=c --compress=9 --verbose --host=localhost --port=5432 -U postgres rc2_dev > "%curr_dir%\dump.bak"
pause

Содержимое bat-файла для восстановления не имеет значения, я считаю, потому что внутри дамп-источника уже поврежден.

Я понятия не имею, что вызывает такое странное поведение !!! Любая помощь будет высоко ценится.

Ответы [ 2 ]

0 голосов
/ 28 ноября 2018

В моем случае проблема заключалась в использовании> для перенаправления вывода.Если я предпочитаю использовать -f, чтобы позволить pg_dump писать прямо в файл, тогда я получаю красиво отформатированный вывод.

Итак, вашим примером будет: pg_dump --blobs --host = localhost --port = 5432 -U postgres-f "% curr_dir% \ dump.bak" rc2_dev

0 голосов
/ 15 марта 2013

Я готов поспорить, что проблема не в дампе / восстановлении, а в обработке конца строки между PostgreSQL и другими программами Windows. Помните, что Windows использует CRLF для EOL шириной в два символа, в то время как UNIX использует CR, а Mac использует LF. Это будет не первый раз, когда конец строк будет ненадлежащим образом поврежден в других местах цепочки инструментов.

Первое, что нужно сделать, это проверить исходный код в вашей базе данных. Для функции выше, это было бы хорошим местом для начала: 

SELECT pro_src FROM pg_proc WHERE proname = 'f_tr_std';

Есть только две возможности. Либо EOL там покалечены, либо нет. Если они искалечены, проверьте остальную часть вашего набора инструментов. Если это не так, проверьте каждую программу, которую вы используете, между dump и restore.

...