Tom Lane wrote:
> The other little problem (which is the reason we like the stderr
> approach in the first place) is that not all the stderr output we want
> to capture comes from code under our control.  This may not be a huge
> problem in production situations, since the main issue in my experience
> is being able to capture dynamic-linker messages when shlib loading fails.
> But it is a stumbling block in the way of any proposals that involve
> having a more structured protocol for the stuff going down the wire :-(
>
>
>   

I don't think that need worry us about CSV output - AFAICS it's 
redirected quite separately from stderr - more like syslog really, so 
the CSV output *is* all from code under our control.

I'm pondering some very simple method of signalling the end of a CSV 
line, like appending a null byte (which we would of course strip out, so 
it would never appear on the file), and only allowing a CSV log rotation 
if we are on a boundary.

cheers

andrew

In response to

• Re: syslogger line-end processing infelicity at 2007-06-01 22:30:10 from Tom Lane

pgsql-hackers by date

Next:	From: Andrew Dunstan	Date: 2007-06-02 02:05:32
	Subject: Re: [HACKERS] like/ilike improvements
Previous:	From: Jim Nasby	Date: 2007-06-02 00:13:54
	Subject: Re: To all the pgsql developers..Have a look at the operators proposed by me in my research paper.