0
votes

Lire le fichier binaire avec PostgreSQL sans pg_read_file

J'ai besoin d'une solution au problème suivant avec un PostgreSQL clair 9.4:

  • lisez un fichier zippé du serveur dans une colonne BYTEA
  • aucune extension autorisée
  • superutilisateur autorisé
  • Postgres Utilisateur a la permission de lire le fichier
  • peut être une fonction utilisateur

    EDIT:

    Le fichier est un chemin de cluster extérieur, de sorte que les fonctions normales augmentent:
    Erreur SQL: Erreur: chemin absolu non autorisé


2 commentaires

Pourquoi avez-vous copié / coller votre précédente réponse supprimée lorsque vous pouvez simplement le découvrir? N'oubliez pas non plus que vous ne pouvez pas récompenser votre prime à vos réponses.


J'ai essayé de non copréter, mais pas assez de votes sont émis pour la restaurer.


3 Réponses :


0
votes

Après beaucoup de recherches, je suis sorti avec la fonction suivante: xxx

cas d'utilisation d'échantillon:

lu depuis le fichier
Sélectionnez File_Read (Concat ('/ TMP /', '28528026BC302546D17CE7E82400AB7E.ZIP')

Colonne de mise à jour

Mettre à jour Custom_Table Set Content = File_Read (nom de fichier)


0 commentaires

1
votes

Voici une fonction simple get_file_contents (Texte du fichier) renvoie BYTEA pour le travail. XXX

  • Utilisation triviale xxx

1 commentaires

Merci, c'est une meilleure version que la mienne et fonctionne bien.



0
votes

Utilisez la fonction intégrée pg_read_binaire_file () . Il est disponible depuis Postgres 9.1 et fait exactement ce que vous voulez. Le manuel:

retourne tout ou partie d'un fichier. Cette fonction est identique à pg_read_file sauf qu'il peut lire des données binaires arbitraires, renvoyer le résultat comme byTea pas texte ; En conséquence, pas de codage Les chèques sont effectués.

Cette fonction est limitée aux superutilisateurs par défaut, mais d'autres utilisateurs peut être accordé exécuter pour exécuter la fonction.

SO à ...

lire un fichier zippé du serveur dans un byTea colonne xxx

considérablement plus rapide que n'importe quelle solution de contournement.

Notez cette restriction, citant Le manuel :

uniquement des fichiers dans le répertoire de cluster de base de données et le log_directory peut être consulté. Utilisez un chemin relatif pour les fichiers dans le cluster répertoire et un chemin correspondant au paramètre de configuration log_directory Pour les fichiers journaux.

Vous pouvez surmonter la restriction de chemin avec un symbole symbolique de votre répertoire DB à tout autre répertoire. Se méfier des implications possibles de sécurité, cependant. Voir:


6 commentaires

Oui, j'ai essayé. Mais pour une raison inconnue, le champ n'est pas chargé avec le contenu du fichier ...


Je ne possède pas la base de données, il appartient à un département Gov.. À l'extérieur, cette demande a été remplie.


@Luizvaz: Tous les messages d'erreur?


Nan. Le champ reste juste vide en utilisant des méthodes normales. La partie la plus étrange est que le contenu est montré à l'aide d'une sélection simple. Mais échoue lorsqu'il est utilisé avec insert ou mise à jour. Je ne peux pas mettre la base de données en mode de trace profond, car il est accessible par plus de 40 000 utilisateurs par jour.


Vous êtes au courant de ce bit du manuel? uniquement des fichiers dans le répertoire de cluster de base de données et le log_directory est accessible. Utilisez un chemin relatif pour les fichiers dans le répertoire de cluster et un chemin correspondant au paramètre de configuration log_directory pour les fichiers journaux. également, la mise à niveau de la version Postgres pourrait aider.


Généralement, si cela fonctionne dans un SELECT , il devrait également fonctionner dans un Insérer ou mise à jour . Cela sonne très impair. Pour être sûr: Utilisez pg_read_binaire_file () , pas pg_read_file () .