COPY er ikke designet til dette. Det er beregnet til at håndtere tabelstrukturerede data, så det kan ikke fungere uden en måde at opdele rækker og kolonner på; der vil altid være nogle tegn, som COPY FROM fortolkes som separatorer, og for hvilke COPY TO vil indsætte en escape-sekvens, hvis den finder en i dine data. Dette er ikke fantastisk, hvis du leder efter en generel fil I/O-facilitet.
Faktisk er databaseservere ikke designet til generel fil I/O. For det første hvad som helst som interagerer direkte med serverens filsystem vil kræve en superbrugerrolle. Hvis det overhovedet er muligt, bør du bare forespørge i tabellen som sædvanligt og håndtere filen I/O på klientsiden.
Når det er sagt, er der et par alternativer:
- Den indbyggede
pg_read_file()funktion, ogpg_file_write()fraadminpackmodul, giver den mest direkte grænseflade til filsystemet, men de er begge begrænset til klyngens datamappe (og jeg vil ikke anbefale at gemme tilfældige brugeroprettede filer der). lo_import()oglo_export()er de eneste indbyggede funktioner, jeg kender til, som omhandler fil-I/O og som har ubegrænset adgang til serverens filsystem (inden for de begrænsninger, host-OS'en pålægger), men Large Object-grænsefladen er ikke særlig brugervenlig ....- Hvis du installerer den upålidelige variant af et proceduresprog som Perl (
plperlu) eller Python (plpythonu), kan du skrive indpakningsfunktioner til det sprogs oprindelige I/O-rutiner. - Der er ikke meget, du ikke kan opnå via
COPY TO PROGRAMhvis du er beslutsom nok - for én, kan duCOPY (SELECT 1) TO PROGRAM 'mv <source_file> <target_file>'at omgå begrænsningerne forpg_file_write()- selvom dette udvisker grænsen mellem SQL og eksterne værktøjer noget (og den, der arver din kodebase, vil sandsynligvis ikke blive imponeret...).