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

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

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

所以你的例子将变成：
pg_dump --blobs --host=localhost --port=5432 -U postgres -f "%curr_dir%\dump.bak" rc2_dev

Answer 2

我敢打赌，问题不在于转储/恢复，而在于 PostgreSQL 和其他 Windows 程序之间的行尾处理。请记住，Windows 使用 CRLF 表示 EOL，即两个字符宽，而 UNIX 使用 CR，Mac 使用 LF。这并不是第一次工具链中其他地方的行尾被不恰当地破坏。

首先要做的是检查数据库中的源代码。对于上面的函数，这将是一个很好的起点：

SELECT pro_src FROM pg_proc WHERE proname = 'f_tr_std'; 

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