COPY is hier niet voor ontworpen. Het is bedoeld om met tabelgestructureerde gegevens om te gaan, dus het kan niet werken zonder een manier om rijen en kolommen te verdelen; er zullen altijd enkele tekens zijn die COPY FROM interpreteert als scheidingstekens, en waarvoor COPY TO zal een ontsnappingsreeks invoegen als het er een in uw gegevens vindt. Dit is niet geweldig als u op zoek bent naar een algemene I/O-voorziening voor bestanden.
In feite zijn databaseservers niet ontworpen voor algemene bestands-I/O. Om te beginnen, alles die rechtstreeks samenwerkt met het bestandssysteem van de server, vereist een superuser-rol. Als het enigszins mogelijk is, moet u de tabel zoals gewoonlijk doorzoeken en de bestands-I/O aan de clientzijde afhandelen.
Dat gezegd hebbende, zijn er een paar alternatieven:
- De ingebouwde
pg_read_file()functie, enpg_file_write()uit hetadminpackmodule, bieden de meest directe interface naar het bestandssysteem, maar ze zijn beide beperkt tot de datadirectory van het cluster (en ik zou niet aanraden om daarin willekeurige, door de gebruiker gemaakte bestanden op te slaan). lo_import()enlo_export()zijn de enige ingebouwde functies die ik ken die rechtstreeks te maken hebben met bestands-I/O en die onbeperkte toegang hebben tot het bestandssysteem van de server (binnen de beperkingen die worden opgelegd door het host-besturingssysteem), maar de interface voor grote objecten is niet bijzonder gebruiksvriendelijk ....- Als je de niet-vertrouwde variant van een proceduretaal zoals Perl (
plperlu) of Python (plpythonu), kunt u wrapper-functies schrijven voor de oorspronkelijke I/O-routines van die taal. - Er is niet veel dat je niet kunt bereiken via
COPY TO PROGRAMals je genoeg vastberaden bent - voor één, kun jeCOPY (SELECT 1) TO PROGRAM 'mv <source_file> <target_file>'te PROGRAMMEREN om de beperkingen vanpg_file_write()te omzeilen - hoewel dit de grens tussen SQL en externe tools enigszins vervaagt (en wie uw codebase erft zal waarschijnlijk niet onder de indruk zijn...).