Vous n'êtes pas identifié(e).
Pages : 1
Bonjour,
J'utilise quelques blobs dans une base PostgreSQL que je viens de migrer de la version 8.3 vers 9.0.1. Tout se passe correctement, sauf pour les blobs.
Mon code (en PHP avec ADODB) n'a pas changé d'une ligne mais il ne fonctionne plus correctement.
Pour ajouter une image, mon code est le suivant:
$strSQL= sprintf("INSERT INTO table_vignette(id_table_vignette) VALUES (%d)",$_GET['id']);
$maCnx->execute($strSQL);
$maCnx->updateBlob("table_vignette","vignette",file_get_contents($tmp),sprintf("id_table_vignette=%d",$_GET['id']));
Dans mon exemple, il s'agit d'une image GIF de 6Ko
Pour récupérer la vignette, mon code est:
$strSQL= sprintf("SELECT vignette FROM table_vignette WHERE id_table_vignettet=%d",$_GET['id']);
$rs=$maCnx->selectLimit($strSQL);
$rs->moveFirst();
$fic= CACHE_SYSTEME.time().'_'.rand(1,100).'.gif';
file_put_contents($fic,$rs->Fields('vignette'));
Génère un fichier de 13Ko (mauvais, évidemment) ???
Le même code fonctionnait parfaitement auparavant.
Le champ vignette est de type bytea, avec le mode de stockage extended (?).
Par avance, merci pour votre aide,
Cordialement,
Jérôme
Hors ligne
Bonjour,
Je pense que la réponse que vous cherchez est dans ce thread : http://forums.postgresql.fr/viewtopic.php?id=1022
Le mode par défaut de conversion entre bytea et texte (pour la récupération par les clients) a changé en 9.0.
Si vous avez davantage de questions, n'hésitez pas à continuer la discussion 
Marc.
Hors ligne
Merci pour votre réponse.
J'étais effectivement passé à côté de ce point.
Cependant, l'utilisation de ces nouvelles fonctions encode et decode doit quelque peu m'échapper; j'ai en effet modifié ma requête
SELECT vignette FROM table_vignette WHERE...
en
SELECT encode(vignette,'escape') FROM table_vignette WHERE...
L'image (éditée sous vim) que j'essaye d'injecter dans PostgreSQL a la forme suivante (extrait du début - en réalité, contient des caractères non imprimables):
GIF89ax^@x^@÷^@^@ò÷ý^@^@^@ßêøÐÁÄ«±|ioÓÅÌßÉÕa^@9Y^@8Á¯º~W~O~TØÍÕÍÀÊÔÈÑ716´¢±ÕÉÓÏÃͬ~X©Ê»ÈȺÆ×ÐÖÖÏÕÓÌÒNF
alors que le résultat du SELECT me donne:
GIF89ax\000x\000\367\000\000\362\367\ (sous forme de caractères imprimables)
C'est certes plus proche du "bon" résultat, car le SELECT sans decode retourne:
G494638396178007800f7000
Pour info, SELECT encode(vignette,'hex') retourne quant à lui:
47494638396178007800f70000f2f7fd
Tout celà n'est pas bien grave car, effectivement, en modifiant le postgresql.conf comme suggéré (bytea_output = 'escape' ), tout est rentré dans l'ordre.
Mais bon, j'aurai aimé comprendre...
En tout cas, encore merci pour votre aide, qui m'a permis de résoudre mon problème.
Hors ligne
N'éditez pas l'image avec vim. Regardez plutôt ce que vaut le fichier avec un éditeur hexadécimal comme hexdump. Vous comprendrez mieux ce qui se passe. Postez le résultat de hexdump si vous voulez, cela nous donnera une base saine sur laquelle discuter.
Marc.
Hors ligne
Je suis d'accord, ce n'est pas élégant... mais suffisant pour constater que les résultats diffèrent.
En théorie, je ne devrais pas avoir besoin du tout d'éditer les résultats, un simple cmp suffit.
Ce que je voulais exprimer, maladroitement j'en conviens, c'est qu'en fonction de l'utilisation ou non de la fonction encode, j'obtenais des résultats différents mais jamais celui souhaité !
Mais bon, ce n'est pas très grave, puisque le problème est simplement résolu en modifiant le postgresql.conf
Cependant, pour ma culture, j'aurai aimé comprendre; a priori, je pense que l'ajout était toujours bon (avec ou sans encode), mais je ne n'ai visiblement pas su trouver la bonne séquence pour le SELECT.
Hors ligne
Je ne sais pas comment vous obtenez ces résultats. Je pense que quelque chose d'autre en modifie l'affichage (le driver ?).
Ce que vous récupérez ne ressemble pas tellement à ce qu'on voit dans la doc : http://docs.postgresql.fr/9.0/datatype-binary.html
Marc.
Hors ligne
Pages : 1
