COPY não foi projetado para isso. Destina-se a lidar com dados estruturados em tabela, portanto, não pode funcionar sem alguma forma de dividir linhas e colunas; sempre haverá alguns caracteres que COPY interpreta como separadores e para os quais COPY TO irá inserir alguma sequência de escape se encontrar uma em seus dados. Isso não é ótimo se você estiver procurando por um recurso geral de E/S de arquivo.

Na verdade, os servidores de banco de dados não são projetados para E/S de arquivo geral. Por um lado, qualquer coisa que interage diretamente com o sistema de arquivos do servidor exigirá uma função de superusuário. Se possível, você deve apenas consultar a tabela como de costume e lidar com a E/S de arquivo no lado do cliente.

Dito isso, existem algumas alternativas:

• O integrado pg_read_file() função e pg_file_write() do adminpack module, fornecem a interface mais direta para o sistema de arquivos, mas ambos são restritos ao diretório de dados do cluster (e eu não recomendaria armazenar arquivos aleatórios criados pelo usuário lá).
• lo_import() e lo_export() são as únicas funções internas que conheço que lidam diretamente com E/S de arquivo e que têm acesso irrestrito ao sistema de arquivos do servidor (dentro das restrições impostas pelo sistema operacional host), mas a interface de objeto grande não é particularmente amigável ao usuário ....
• Se você instalar a variante não confiável de uma linguagem procedural como Perl (plperlu ) ou Python (plpythonu ), você pode escrever funções de wrapper para as rotinas de E/S nativas dessa linguagem.
• Não há muito que você não possa realizar via COPY TO PROGRAM se você estiver determinado o suficiente - por um lado, você pode COPY (SELECT 1) TO PROGRAM 'mv <source_file> <target_file>' para contornar as limitações de pg_file_write() - embora isso borre um pouco a linha entre SQL e ferramentas externas (e quem herdar sua base de código provavelmente não ficará impressionado...).