COPY ist dafür nicht ausgelegt. Es ist für den Umgang mit tabellenstrukturierten Daten gedacht, daher kann es nicht ohne eine Möglichkeit zum Teilen von Zeilen und Spalten funktionieren. es wird immer einige Zeichen geben, die COPY FROM sind als Trennzeichen interpretiert, und für die COPY TO fügt eine Escape-Sequenz ein, wenn es eine in Ihren Daten findet. Das ist nicht so toll, wenn Sie nach einer allgemeinen Datei-I/O-Einrichtung suchen.
Tatsächlich sind Datenbankserver nicht für allgemeine Datei-I/O ausgelegt. Zum einen alles der direkt mit dem Dateisystem des Servers interagiert, erfordert eine Superuser-Rolle. Wenn möglich, sollten Sie die Tabelle einfach wie gewohnt abfragen und die Datei-I/O auf der Client-Seite erledigen.
Allerdings gibt es einige Alternativen:
- Der eingebaute
pg_read_file()-Funktion undpg_file_write()aus demadminpack-Modul bieten die direkteste Schnittstelle zum Dateisystem, aber beide sind auf das Datenverzeichnis des Clusters beschränkt (und ich würde nicht empfehlen, zufällige, von Benutzern erstellte Dateien dort zu speichern). lo_import()undlo_export()sind die einzigen integrierten Funktionen, die ich kenne, die sich direkt mit Datei-I/O befassen und uneingeschränkten Zugriff auf das Dateisystem des Servers haben (innerhalb der vom Host-Betriebssystem auferlegten Einschränkungen), aber die Large Object-Schnittstelle ist nicht besonders benutzerfreundlich ....- Wenn Sie die nicht vertrauenswürdige Variante einer prozeduralen Sprache wie Perl installieren (
plperlu) oder Python (plpythonu), können Sie Wrapper-Funktionen für die nativen I/O-Routinen dieser Sprache schreiben. - Es gibt nicht viel, was Sie nicht über
COPY TO PROGRAMerreichen können wenn Sie entschlossen genug sind - zum einen könnten SieCOPY (SELECT 1) TO PROGRAM 'mv <source_file> <target_file>'um die Beschränkungen vonpg_file_write()zu umgehen - obwohl dies die Grenze zwischen SQL und externen Tools etwas verwischt (und wer Ihre Codebasis erbt, wird wahrscheinlich nicht beeindruckt sein ...).
