COPY no está diseñado para esto. Está destinado a tratar con datos estructurados en tablas, por lo que no puede funcionar sin alguna forma de dividir filas y columnas; siempre habrá algunos caracteres que COPY FROM interpreta como separadores, y para los cuales COPY TO insertará alguna secuencia de escape si encuentra una en sus datos. Esto no es excelente si está buscando una instalación de E/S de archivos general.
De hecho, los servidores de bases de datos no están diseñados para la E/S general de archivos. Por un lado, cualquier cosa que interactúa directamente con el sistema de archivos del servidor requerirá un rol de superusuario. Si es posible, solo debe consultar la tabla como de costumbre y tratar con la E/S del archivo en el lado del cliente.
Dicho esto, hay algunas alternativas:
- El incorporado
pg_read_file()ypg_file_write()desde eladminpackproporciona la interfaz más directa al sistema de archivos, pero ambos están restringidos al directorio de datos del clúster (y no recomendaría almacenar allí archivos aleatorios creados por usuarios). lo_import()ylo_export()son las únicas funciones integradas que conozco que se ocupan directamente de la E/S de archivos y que tienen acceso ilimitado al sistema de archivos del servidor (dentro de las restricciones impuestas por el sistema operativo host), pero la interfaz de objetos grandes no es particularmente fácil de usar ....- Si instala la variante no confiable de un lenguaje de procedimiento como Perl (
plperlu) o Python (plpythonu), puede escribir funciones contenedoras para las rutinas de E/S nativas de ese lenguaje. - No hay mucho que no puedas lograr a través de
COPY TO PROGRAMsi está lo suficientemente determinado, por ejemplo, podríaCOPY (SELECT 1) TO PROGRAM 'mv <source_file> <target_file>'para evitar las limitaciones depg_file_write()- aunque esto desdibuja un poco la línea entre SQL y las herramientas externas (y quienquiera que herede su base de código probablemente no quedará impresionado...).
