COPY
není na to určen. Má pracovat s tabulkově strukturovanými daty, takže nemůže fungovat bez nějakého způsobu dělení řádků a sloupců; vždy budou nějaké znaky, které COPY FROM
interpretuje jako oddělovače a pro které COPY TO
vloží nějakou escape sekvenci, pokud ji najde ve vašich datech. To není skvělé, pokud hledáte obecné I/O zařízení.
Databázové servery ve skutečnosti nejsou určeny pro obecný souborový I/O. Jednak cokoli který přímo spolupracuje se systémem souborů serveru, bude vyžadovat roli superuživatele. Pokud je to jen trochu možné, měli byste se pouze dotazovat na tabulku jako obvykle a zabývat se I/O souboru na straně klienta.
To znamená, že existuje několik alternativ:
- Vestavěný
pg_read_file()
funkce apg_file_write()
zadminpack
modul, poskytují nejpřímější rozhraní k systému souborů, ale oba jsou omezeny na datový adresář clusteru (a nedoporučoval bych tam ukládat náhodné soubory vytvořené uživateli). lo_import()
alo_export()
jsou jediné vestavěné funkce, o kterých vím, které se zabývají přímo I/O souborů a které mají neomezený přístup k souborovému systému serveru (v rámci omezení uložených hostitelským OS), ale rozhraní velkých objektů není nijak zvlášť uživatelsky přívětivé ....- Pokud si nainstalujete nedůvěryhodnou variantu procedurálního jazyka, jako je Perl (
plperlu
) nebo Python (plpythonu
), můžete psát funkce wrapper pro nativní I/O rutiny daného jazyka. - Není toho mnoho, čeho byste nemohli dosáhnout pomocí
COPY TO PROGRAM
pokud jste dostatečně odhodláni - pro jednoho můžeteCOPY (SELECT 1) TO PROGRAM 'mv <source_file> <target_file>'
obejít omezenípg_file_write()
- i když to poněkud stírá hranice mezi SQL a externími nástroji (a kdokoli zdědí vaši kódovou základnu, pravděpodobně nebude ohromen...).