Question

简明扼要：转储/恢复过程使我的函数源代码看起来很难看！上帝知道为什么，但有些东西为我格式化的源代码添加了额外的换行符，这种方式让我非常生气（并且让我更难以阅读我的代码）。只是我恢复数据库后会发生什么的一个小例子：

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文件的内容是无关紧要的，因为转储源内部已经损坏了。

我完全不知道是什么导致了这种奇怪的行为！任何帮助将不胜感激。

Answer 1

我愿意打赌问题不在于转储/恢复，而在于PostgreSQL和其他Windows程序之间的行尾处理。请记住，Windows使用CRLF用于EOL，这是两个字符宽，而UNIX使用CR而Mac使用LF。这不是第一次在工具链的其他地方不正确地破坏行的结束。

要做的第一件事是检查数据库中的源代码。对于上述功能，这将是一个很好的起点：

SELECT pro_src FROM pg_proc WHERE proname = 'f_tr_std';

只有两种可能性。要么EOL在那里被破坏，要么他们没有。如果它们被损坏，请检查工具链的其余部分。如果不是，请检查转储和恢复之间使用的每个程序。

Answer 2

就我而言，问题在于使用>重定向输出。如果我宁愿使用-f来让pg_dump直接写入文件，那么我会得到格式正确的输出。

因此您的示例将变为： pg_dump --blobs --host = localhost --port = 5432 -U postgres -f“％curr_dir％\ dump.bak” rc2_dev

杂散换行符会破坏转储/恢复上的源代码

2 个答案: