Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
+1 on that. The problem of ensuring atomic output remains though
(see nearby complaints from George Pavlov and others).
Is that the one you suggested trying to fix by calling write() instead
of fp
Andrew Dunstan wrote:
>
>
> Magnus Hagander wrote:
>>> My second thought is that we should quite possibly abandon this
>>> translation altogether - we know that our COPY code is quite happy with
>>> either style of line ending, as long as the file is consistent, and also
>>> many Windows programs
Magnus Hagander wrote:
My second thought is that we should quite possibly abandon this
translation altogether - we know that our COPY code is quite happy with
either style of line ending, as long as the file is consistent, and also
many Windows programs will quite happily read files with Unix s
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
i
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> +1 on that. The problem of ensuring atomic output remains though
>> (see nearby complaints from George Pavlov and others).
> Is that the one you suggested trying to fix by calling write() instead
> of fprintf()? If so, I can't think
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
I have been looking at the syslogger code in connection with the CSV log
output proposal, and I'm quite concerned about the way it translates
every \n into \r\n for Windows output.
...
My second thought is that we should quite pos
Andrew Dunstan wrote:
>
> I have been looking at the syslogger code in connection with the CSV log
> output proposal, and I'm quite concerned about the way it translates
> every \n into \r\n for Windows output. This has several problems, not
> least of which is that we can by no means assume that
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> I have been looking at the syslogger code in connection with the CSV log
> output proposal, and I'm quite concerned about the way it translates
> every \n into \r\n for Windows output.
> ...
> My second thought is that we should quite possibly abandon
I have been looking at the syslogger code in connection with the CSV log
output proposal, and I'm quite concerned about the way it translates
every \n into \r\n for Windows output. This has several problems, not
least of which is that we can by no means assume that every \n has no
semantic si
