The \i file is opened in binary mode because we don't want control-Z to
mark end-of-file.  We have to do this because bytea allows a stream of
binary data and control-Z might be in there.  The parser knows if the
control-Z is in quotes or not, but the file I/O routines to not and this
would cause a problem.  There is also the problem if literal carriage
returns in COPY, though that shouldn't happen.

What is happening in your function and comments is that the original
line endings are preserved in the dump file and are recreated on the
Unix side.  The good news is that it shouldn't affect the operation of
the database, but I can see how it would be annoying.  

Function and comments are just _strings_ to PostgreSQL, so we have no
good way of cleaning the output up, unless we hack pg_dump to somehow
change line endings when outputting such information, though currently we
don't.  The would perhaps cause problems in viewing the functions if
restored in Win32.

Fixing it at the \i level is too crude because it might remove carriage
returns that are wanted in the input stream.

We are open to ideas on how to improve this.


Luiz K. Matsumura wrote:
> Hi,
> I need to backup my database with pg_dump and recover it in other 
> windows machine.
> I recover my database running the pg_dump generated script in psql with 
> \i command
> At each time I do this operation ,  misteriously the space between lines 
> multiplies in my functions and comments.
> Well, I discover that when I use \i <file> command in psql with a file 
> generated in windows format ( CR+LF terminated lines) psql actually 
> sends the CR character at each line break to postgres, causing this effect.
> I make a change in input.c that resolve this problem, but I'm not a 
> expert in c, therefore if someone have a better solution,
> please do the necessary changes.
> Thanks in advance.

> *** input.c.ori       2005-03-09 21:05:36.000000000 -0300
> --- input.c   2005-03-09 22:40:32.000000000 -0300
> ***************
> *** 142,147 ****
> --- 142,152 ----
>               if ([buffer.len - 1] == '\n')
>               {
>             [buffer.len - 1] = '\0';
> +                     /* in case of CR + LF  */
> +                     if ([buffer.len - 2] == '\r')
> +                     {
> +                   [buffer.len - 2] = '\0';
> +                     }
>                       return;
>               }
>       }

> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

  Bruce Momjian                        |               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

Reply via email to