34.4. Fonctions du côté serveur

» » »

Précédent	Niveau supérieur	Suivant
34.3. Interfaces client	Sommaire	34.5. Programme d'exemple

34.4. Fonctions du côté serveur

Les fonctions côté serveur conçues pour la manipulation des Large Objects en SQL sont listées dans Tableau 34.1.

Tableau 34.1. Fonctions SQL orientées Large Object

Fonction Description Exemple(s)
`lo_from_bytea` ( `loid` `oid`, `data` `bytea` ) → `oid` Crée un large objet et stocke des `data` dedans. Si le paramètre `loid` est zéro, alors le système va choisir un OID libre, sinon cet OID est utilisé (avec une erreur s'il existe déjà un large objet sur ce OID). En cas de succès, l'OID du large objet est retourné. `lo_from_bytea(0, '\xffffff00')` → `24528`
`lo_put` ( `loid` `oid`, `offset` `bigint`, `data` `bytea` ) → `void` Écrit `data` en commençant par l'offset donné à l'intérieur du large objet, le large objet est aggrandi si nécessaire. `lo_put(24528, 1, '\xaa')` →
`lo_get` ( `loid` `oid` [, `offset` `bigint`, `length` `integer` ] ) → `bytea` Extrait le contenu du large objet, ou une sous-chaîne de celui-ci. `lo_get(24528, 0, 3)` → `\xffaaff`

Fonction

Description

Exemple(s)

lo_from_bytea ( loid oid, data bytea ) → oid

Crée un large objet et stocke des data dedans. Si le paramètre loid est zéro, alors le système va choisir un OID libre, sinon cet OID est utilisé (avec une erreur s'il existe déjà un large objet sur ce OID). En cas de succès, l'OID du large objet est retourné.

lo_from_bytea(0, '\xffffff00') → 24528

lo_put ( loid oid, offset bigint, data bytea ) → void

Écrit data en commençant par l'offset donné à l'intérieur du large objet, le large objet est aggrandi si nécessaire.

lo_put(24528, 1, '\xaa') →

lo_get ( loid oid [, offset bigint, length integer ] ) → bytea

Extrait le contenu du large objet, ou une sous-chaîne de celui-ci.

lo_get(24528, 0, 3) → \xffaaff

Il existe d'autres fonctions côté serveur correspondant à chacune des fonctions côté client décrites précédemment. En fait, la plupart des fonctions côté client sont simplement des interfaces vers l'équivalent côté serveur. Celles qu'il est possible d'appeler via des commandes SQL sont lo_creat, lo_create, lo_create, lo_unlink, lo_import et lo_export. Voici des exemples de leur utilisation :

CREATE TABLE image (
    nom             text,
    donnees         oid
);

SELECT lo_creat(-1);       -- renvoie l'OID du nouvel objet large

SELECT lo_create(43213);   -- tente de créer l'objet large d'OID 43213

SELECT lo_unlink(173454);  -- supprime l'objet large d'OID 173454

INSERT INTO image (nom, donnees)
    VALUES ('superbe image', lo_import('/etc/motd'));

INSERT INTO image (nom, donnees)  -- identique à ci-dessus, mais précise l'OID à utiliser
    VALUES ('superbe image', lo_import('/etc/motd', 68583));

SELECT lo_export(image.donnees, '/tmp/motd') FROM image
    WHERE nom = 'superbe image';

Les fonctions lo_import et lo_export côté serveur se comportent considérablement différemment de leurs analogues côté client. Ces deux fonctions lisent et écrivent des fichiers dans le système de fichiers du serveur en utilisant les droits du propriétaire du serveur de base de données. Du coup, par défaut, leur utilisation est restreinte aux superutilisateurs PostgreSQL. Au contraire des fonctions côté serveur, les fonctions d'import et d'export côté client lisent et écrivent des fichiers dans le système de fichiers du client en utilisant les droits du programme client. Les fonctions côté client ne nécessitent pas de droits particuliers sur la base, sauf celui de lire et écrire le Large Object en question.

Attention

Il est possible de donner (GRANT) le droit d'utiliser les fonctions serveurs lo_import et lo_export à des utilisateurs standards mais les implications sur la sécurité doivent être mesurées avec attention. Un utilisateur mal intentionné avec de tels droits pourrait facilement les utiliser pour devenir superutilisateur (par exemple en réécrivant les fichiers de configuration du serveur) ou pourrait attaquer le reste du système de fichiers du serveur, sans avoir à se soucier d'obtenir les droits de superutilisateur de la base de données. L'accès aux rôles ayant de tels droits doit de ce fait être gardé très précautionneusement, tout comme l'accès aux rôles superutilisateur. Néanmoins, si l'utilisation des fonctions serveurs lo_import et lo_export sont nécessaires pour certaines tâches de routine, il est plus sûr d'utiliser un rôle avec ces droits qu'un rôle avec les droits complets du superutilisateur car cela aide à réduire le risque de dommages pour les erreurs accidentelles.

Les fonctionnalités de lo_read et lo_write sont aussi disponibles via des appels côté serveur mais les noms des fonctions diffèrent des interfaces côté client du fait qu'elles ne possèdent pas de tiret bas. Vous devez appeler ces fonctions avec loread et lowrite.