Vous n'êtes pas identifié(e).
Pages : 1
salut , j'ai une table img qui a la structure suivante :
CREATE TABLE img
(
"nomImage" character(50) NOT NULL,
imgbyte bytea,
CONSTRAINT img_pkey PRIMARY KEY ("nomImage")
)lorsque j'essaie d'inserer une image avec la requete suivante j'ai une erreur .
INSERT INTO img VALUES ('image test',lo_import('C://test//s1.jpg'));ERREUR: la colonne « imgbyte » est de type bytea mais l'expression est de type oid
État SQL :42804
Astuce : Vous devez réécrire l'expression ou lui appliquer une transformation de type.Que faire ?
Merci d'avance.
Hors ligne
Bonsoir
Quelle version de PostgreSQL utilisez vous ?
Christophe Chauvet
Directeur Technique
Sylëam Info Services
Mon site
Hors ligne
Bonjour,
Dans le code de la création de la table, vous devez remplacer le type de données "bytea" par "oid", comme indiqué dans la doc:
http://docs.postgresqlfr.org/8.3/lo-funcs.html
Bonne journée,
Jean-Paul Argudo
https://www.postgresql.fr
https://www.crunchydata.com
Hors ligne
lo_import ne sert que si vous utilisez des Large Objects. Cette colonne est déclarée comme un bytea, donc pas du tout la même chose.
La première chose à savoir est le type de données que vous voulez gérer. Pour une image, vous avez le choix entre bytea et Large Object. Si vous voulez utiliser les ordres du type lo_import et compagnie, il faut utiliser des Large Objects. Dans ce cas, lire http://docs.postgresql.fr/8.3/largeobjects.html pour les détails. Par contre, si vous voulez que l'image soit stockée dans cette même table en passant par une colonne bytea, vous ne pourrez pas utiliser les fonctions lo_*. Voir http://docs.postgresqlfr.org/8.3/datatype-binary.html pour les détails.
Guillaume.
Hors ligne
merci pour vos réponses.
Quel est le type le plus adapté aux images le bytea ou le oid ?
Hors ligne
Je dirais qu'il est plus facile de maintenir des tables contenant des bytea. Mais, strictement parlant, le bytea et le Large Object sont aussi bien adaptés l'un que l'autre.
Guillaume.
Hors ligne
plus facile ?
Hors ligne
Oui. Un seul exemple. Quand tu veux supprimer une image, tu vas faire un DELETE de la ligne dans ta table. Tout à fait ce qu'il faut faire pour une colonne bytea. Par contre, si tu as une colonne oid qui pointe vers un Large Object, tu dois aussi penser à supprimer le Large Object.
Autre problème : il faut pouvoir vacuumer la table système qui contient tous les Larges Objects.
Bref, que des détails ainsi mais qui rendent la vie difficile lorsqu'on utilise les Large Objects. (À noter les modules contrib lo et vacuumlo qui cherchent à faciliter les choses, mais avec un bytea, pas besoin de tout ça)
Guillaume.
Hors ligne
Ok, j'ai remplacé les oid par des bytea mais j'ai pas trouvé l'équivalent des fonctions lo_import et lo_export dans la doc, pouvez m'aider svp?
Dernière modification par isoman (29/01/2009 10:40:40)
Hors ligne
Ce type de champ se gère comme les autres. Il n'y a pas de fonctions spéciales pour ça.
Guillaume.
Hors ligne
je vais formuler la question autrement, si je veux insérer une image dans un champ bytea avec une requete sql dans pgAdmin 3 ,j'utilise quelle fonction pour designer la source de l'image ?
Hors ligne
Ce n'est pas possible avec ce type de champ car il faut exécuter une requête du type :
INSERT INTO ta_table (le_champ_bytea) VALUES ('le contenu du fichier image');
Guillaume.
Hors ligne
supposons que je travaille avec un serveur distant , si j'utilise le oid pour stocker un objet a partir du client , est ce que l'objet en entier est transmis au serveur ou le champ oid va pointer vers le fichier du client ?
Merci d'avance.
Hors ligne
Le fichier entier est transmis. C'est vrai pour un Large Object comme pour un bytea. La seule différence est qu'il existe des fonctions PostgreSQL pour envoyer le fichier vers un Large Object, alors qu'il faut utiliser les fonctions du langage utilisé pour lire le fichier puis l'intégrer dans un bytea.
Guillaume.
Hors ligne
Pages : 1