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 (firstname.lastname@example.org)
To make changes to your subscription: