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 | http://candle.pha.pa.us pgman@candle.pha.pa.us | (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 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
