COPY non è progettato per questo. È pensato per gestire dati strutturati in tabelle, quindi non può funzionare senza un modo per dividere righe e colonne; ci saranno sempre dei caratteri che COPY FROM interpreta come separatori e per i quali COPY TO inserirà una sequenza di escape se ne trova una nei tuoi dati. Questo non è eccezionale se stai cercando una struttura di I/O di file generale.
In effetti, i server di database non sono progettati per l'I/O di file generale. Tanto per cominciare, qualsiasi cosa che interagisce direttamente con il file system del server richiederà un ruolo di superutente. Se possibile, dovresti semplicemente interrogare la tabella come al solito e gestire l'I/O del file sul lato client.
Detto questo, ci sono alcune alternative:
- Il integrato
pg_read_file()funzione epg_file_write()daladminpackmodulo, forniscono l'interfaccia più diretta al file system, ma sono entrambi limitati alla directory dei dati del cluster (e non consiglierei di archiviare file casuali creati dall'utente). lo_import()elo_export()sono le uniche funzioni integrate che conosco che si occupano direttamente dell'I/O di file e che hanno accesso illimitato al file system del server (entro i vincoli imposti dal sistema operativo host), ma l'interfaccia Large Object non è particolarmente intuitiva ....- Se installi la variante non attendibile di un linguaggio procedurale come Perl (
plperlu) o Python (plpythonu), puoi scrivere funzioni wrapper per le routine I/O native di quella lingua. - Non c'è molto che non puoi realizzare tramite
COPY TO PROGRAMse sei abbastanza determinato, per esempio, potrestiCOPY (SELECT 1) TO PROGRAM 'mv <source_file> <target_file>'per aggirare le limitazioni dipg_file_write()- anche se questo offusca un po' il confine tra SQL e strumenti esterni (e chiunque erediti la tua base di codice probabilmente non sarà impressionato...).
