Hi all,
it’s my first time here, so please let me know if I’m doing something wrong. 
I’m a developer, heavy PG user, but I’ve never hacked it before. Last week at 
work we had to produce a quite big CSV data file which should be used as input 
by another piece of software.

Since the file must be produced on a daily basis, is big, and it contains data 
stored in our PG database, letting PG produce the file itself seemed the right 
approach. Unfortunately the target software is, let say, “legacy” software and 
can only accept CRLF as EOL character. Since our PG is installed on a Linux 
server COPY TO results in a CSV file with LF as EOL, forcing us to pass the 
file a second time to convert EOL, which is inconvenient.

My idea was to extend the COPY TO command to accept an EOL option as it already 
does with the DELIMITER option. To keep it simple we can limit the EOL choice 
to CR, LF or CRLF to avoid unusual output, and also keep the current behaviour 
when no EOL option is given. I was also wondering if an EOL option could be 
useful also for the text output format or not.

I spent the weekend reading the COPY command source code and its grammar 
definition and I think I can patch it by myself, submit the patch here and wait 
for your review. However before starting this in my spare time I wanted to know 
if you, as the PG hackers community, would be against a similar proposal for 
any reason, and if so why.

Thanks in advance,

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to