Extending COPY TO
От | Andrea Riciputi |
---|---|
Тема | Extending COPY TO |
Дата | |
Msg-id | 178A22CE-45D3-452D-926E-AFC4904ECF3B@gmail.com обсуждение исходный текст |
Ответы |
Re: Extending COPY TO
Re: Extending COPY TO |
Список | pgsql-hackers |
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 neverhacked it before. Last week at work we had to produce a quite big CSV data file which should be used as input by anotherpiece 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 producethe file itself seemed the right approach. Unfortunately the target software is, let say, “legacy” software and canonly accept CRLF as EOL character. Since our PG is installed on a Linux server COPY TO results in a CSV file with LF asEOL, 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 itsimple we can limit the EOL choice to CR, LF or CRLF to avoid unusual output, and also keep the current behaviour whenno 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 ifyou, as the PG hackers community, would be against a similar proposal for any reason, and if so why. Thanks in advance, Andrea
В списке pgsql-hackers по дате отправления: