Skip site navigation (1) Skip section navigation (2)

Re: [PATCHES] problem with CR+LF in files in psql \i command

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Euler Taveira de Oliveira <eulerto(at)yahoo(dot)com(dot)br>
Cc: "Luiz K(dot) Matsumura" <luiz(at)planit(dot)com(dot)br>,PostgreSQL-development <pgsql-hackers(at)postgreSQL(dot)org>
Subject: Re: [PATCHES] problem with CR+LF in files in psql \i command
Date: 2005-03-26 17:59:48
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-patches
Euler Taveira de Oliveira wrote:
> Hi Bruce,
> > 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.
> > 
> Agreed.
> > Fixing it at the \i level is too crude because it might remove
> > carriage
> > returns that are wanted in the input stream.
> > 
> Agreed.
> > We are open to ideas on how to improve this.
> > 
> What about another option to pg_dump to indicate such a thing? Maybe -l
> or --change-line [m|w|u]

Yea, we could do that, but pg_dump seems like the wrong place to handle
this.  For example, imagine if you have a mix of Win32 and Unix clients
--- if you create a function under Win32, it will look double-spaced to
a Unix client.

Ideally we would auto-convert the function text to the native client
format, but the function text is displayed via a SELECT, so how would we
special-case the function body SELECT output to output using the native
client line endings?

I am thinking we need a functions like unix_eol(), dos_eol(), or even
client_eol() to allow conversion of the output to an end-of-line format
matching the client.   One nifty trick would be to modify the data type
of pg_proc.prosrc to auto-convert end-of-line format to match the
client.  The problem there is that it special-cases a column just to fix
this single issue.  Perhaps the ability to use functions like this is
the proper approach because they can be used in other places as well.

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

In response to

pgsql-hackers by date

Next:From: Tom LaneDate: 2005-03-26 18:22:03
Subject: Re: minor windows & cygwin regression failures on stable branch
Previous:From: Andrew DunstanDate: 2005-03-26 16:22:02
Subject: Re: minor windows & cygwin regression failures on stable

pgsql-patches by date

Next:From: Robert CreagerDate: 2005-03-27 06:00:53
Subject: Re: BUG #1563: wrong week returnded by date_trunc('week',
Previous:From: Euler Taveira de OliveiraDate: 2005-03-26 11:32:25
Subject: Re: problem with CR+LF in files in psql \i command

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group