Comment exporter des fichiers en texte intégral avec SQL ?

COPY n'est pas conçu pour cela. Il est destiné à traiter des données structurées en tableaux, il ne peut donc pas fonctionner sans un moyen de diviser les lignes et les colonnes ; il y aura toujours des caractères qui COPY FROM interprète comme des séparateurs, et pour lesquels COPY TO insérera une séquence d'échappement s'il en trouve une dans vos données. Ce n'est pas génial si vous recherchez une fonction d'E/S de fichier générale.

En fait, les serveurs de base de données ne sont pas conçus pour les E/S générales sur les fichiers. D'une part, n'importe quoi qui interagit directement avec le système de fichiers du serveur nécessitera un rôle de superutilisateur. Si possible, vous devez simplement interroger la table comme d'habitude et gérer les E/S de fichier côté client.

Cela dit, il existe quelques alternatives :

• Le intégré pg_read_file() fonction, et pg_file_write() depuis le adminpack module, fournissent l'interface la plus directe avec le système de fichiers, mais ils sont tous deux limités au répertoire de données du cluster (et je ne recommanderais pas d'y stocker des fichiers aléatoires créés par l'utilisateur).
• lo_import() et lo_export() sont les seules fonctions intégrées que je connaisse qui traitent directement des E/S de fichiers et qui ont un accès illimité au système de fichiers du serveur (dans les limites imposées par le système d'exploitation hôte), mais l'interface Large Object n'est pas particulièrement conviviale ....
• Si vous installez la variante non approuvée d'un langage procédural tel que Perl (plperlu ) ou Python (plpythonu ), vous pouvez écrire des fonctions wrapper pour les routines d'E/S natives de ce langage.
• Il n'y a pas grand-chose que vous ne pouvez pas accomplir via COPY TO PROGRAM si vous êtes suffisamment déterminé - pour commencer, vous pouvez COPY (SELECT 1) TO PROGRAM 'mv <source_file> <target_file>' pour contourner les limitations de pg_file_write() - bien que cela brouille quelque peu la frontière entre SQL et les outils externes (et celui qui hérite de votre base de code ne sera probablement pas impressionné...).