COPY nie jest do tego przeznaczony. Jest przeznaczony do obsługi danych o strukturze tabeli, więc nie może działać bez pewnego sposobu dzielenia wierszy i kolumn; zawsze będą jakieś znaki, które COPY FROM interpretuje jako separatory i dla których COPY TO wstawi jakąś sekwencję ucieczki, jeśli znajdzie ją w twoich danych. Nie jest to dobre rozwiązanie, jeśli szukasz ogólnej funkcji we/wy plików.
W rzeczywistości serwery baz danych nie są przeznaczone do ogólnych operacji we/wy na plikach. Po pierwsze, wszystko który współdziała bezpośrednio z systemem plików serwera, będzie wymagał roli administratora. Jeśli to w ogóle możliwe, powinieneś po prostu wysłać zapytanie do tabeli jak zwykle i zająć się plikami I/O po stronie klienta.
To powiedziawszy, istnieje kilka alternatyw:
- Wbudowany
pg_read_file()funkcja ipg_file_write()zadminpackzapewniają najbardziej bezpośredni interfejs do systemu plików, ale oba są ograniczone do katalogu danych klastra (i nie zalecałbym przechowywania tam losowych plików utworzonych przez użytkowników). lo_import()ilo_export()są jedynymi znanymi mi wbudowanymi funkcjami, które bezpośrednio zajmują się plikowym I/O i które mają nieograniczony dostęp do systemu plików serwera (w ramach ograniczeń nałożonych przez system operacyjny hosta), ale interfejs Large Object nie jest szczególnie przyjazny dla użytkownika ....- Jeśli zainstalujesz niezaufany wariant języka proceduralnego, takiego jak Perl (
plperlu) lub Pythona (plpythonu), możesz pisać funkcje opakowujące dla natywnych procedur I/O tego języka. - Niewiele nie można osiągnąć za pomocą
COPY TO PROGRAMjeśli jesteś wystarczająco zdeterminowany - na przykład możeszCOPY (SELECT 1) TO PROGRAM 'mv <source_file> <target_file>'aby obejść ograniczeniapg_file_write()- choć to nieco zaciera granicę między SQL a narzędziami zewnętrznymi (a kto odziedziczy twój kod, prawdopodobnie nie będzie pod wrażeniem...).
