Extending COPY TO

Поиск
Список
Период
Сортировка
От Andrea Riciputi
Тема Extending COPY TO
Дата
Msg-id 178A22CE-45D3-452D-926E-AFC4904ECF3B@gmail.com
обсуждение исходный текст
Ответы Re: Extending COPY TO  (Heikki Linnakangas <hlinnakangas@vmware.com>)
Re: Extending COPY TO  (Stephen Frost <sfrost@snowman.net>)
Список 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 по дате отправления:

Предыдущее
От: Heikki Linnakangas
Дата:
Сообщение: Re: RLS feature has been committed
Следующее
От: Heikki Linnakangas
Дата:
Сообщение: Re: Extending COPY TO