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()zadminpackmodul, 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 PROGRAMpokud 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...).