COPY не е предназначен за това. Предназначен е да се справя с таблично структурирани данни, така че не може да работи без някакъв начин за разделяне на редове и колони; винаги ще има някои знаци, които COPY FROM интерпретира като разделители и за които COPY TO ще вмъкне някаква екранираща последователност, ако намери такава във вашите данни. Това не е чудесно, ако търсите общо I/O средство за файлове.
Всъщност сървърите на бази данни не са проектирани за общ вход/изход на файлове. От една страна, всичко който взаимодейства директно с файловата система на сървъра, ще изисква роля на суперпотребител. Ако изобщо е възможно, трябва просто да направите заявка към таблицата, както обикновено, и да се справите с I/O на файла от страна на клиента.
Въпреки това има няколко алтернативи:
- Вграденият
pg_read_file()функция иpg_file_write()отadminpackмодул, осигуряват най-директния интерфейс към файловата система, но и двата са ограничени до директорията с данни на клъстера (и не бих препоръчал съхраняването на произволно създадени от потребителя файлове там). lo_import()иlo_export()са единствените вградени функции, за които знам, които се занимават директно с файлов I/O и които имат неограничен достъп до файловата система на сървъра (в рамките на ограниченията, наложени от хост ОС), но интерфейсът за големи обекти не е особено удобен за потребителя ....- Ако инсталирате ненадеждния вариант на процедурен език като Perl (
plperlu) или Python (plpythonu), можете да напишете функции за обвивка за родните I/O рутинни процедури на този език. - Няма много неща, които не можете да постигнете чрез
COPY TO PROGRAMако сте достатъчно решени - например можете даCOPY (SELECT 1) TO PROGRAM 'mv <source_file> <target_file>'за да заобиколите ограниченията наpg_file_write()- въпреки че това донякъде размива границата между SQL и външните инструменти (и който наследи вашата кодова база вероятно няма да бъде впечатлен...).
