pg_lo_write

(PHP 4 >= 4.2.0, PHP 5, PHP 7, PHP 8)

pg_lo_write — Écrit un objet de grande taille PostgreSQL

Description

pg_lo_write(resource $large_object, string $data, int $len = ?): int

pg_lo_write() écrit des données à l'intérieur d'un objet de grande taille à la position courante.

Pour manipuler un objet de grande taille (lo), il est nécessaire de placer les opérations dans un bloc de transaction.

Note:
Auparavant, cette fonction s'appelait pg_lowrite().

Liste de paramètres

large_object: Ressource objet de grande taille (LOB) PostgreSQL retournée par pg_lo_open().
data: Les données à être écrites dans l'objet de grande taille. Si len est spécifié et est inférieur à la grandeur de data, seul les len octets y seront écrits.
len: Un nombre maximal d'octets à écrire. Il doit être supérieur à zéro et inférieur à la grandeur de data. Cet argument est optionnel, s'il est omis, il prendra par défaut la grandeur de data.

Valeurs de retour

Le nombre d'octets écrit dans l'objet de grande taille ou false en cas d'erreur.

Exemples

Exemple #1 Exemple avec pg_lo_write()


<?php
   $doc_oid = 189762345;
   $data = "Ceci écrasera le début de l'objet de grande taille.";
   $database = pg_connect("dbname=jacarta");
   pg_query($database, "begin");
   $handle = pg_lo_open($database, $doc_oid, "w");
   $data = pg_lo_write($handle, $data);
   pg_query($database, "commit");
?>

Voir aussi

pg_lo_create() - Crée un objet de grande taille PostgreSQL
pg_lo_open() - Ouvre un objet de grande taille PostgreSQL

add a note

User Contributed Notes 2 notes

down

cedric at isoca.com ¶

23 years ago


Be aware when you modify a lo with pg_lowrite() to remove first the old one : if the new lo is smaller than the one before, it only overwrite the begining and you keep the end of the old lo (open with "w" parameter, PHP 4.04 Linux RH).

down

-1

nandrews at logictree dot co dot uk ¶

20 years ago


Using php 4.3.0 and PostgreSQL 7.3.1

I can write a simple script in which pg_lo_write seems to always return 1 and not the number of bytes written, as evidenced by extracting the data through another means.

Further more, I can make this pg_lo_write fail, or at least fail to write all the data it's pretty difficult to tell without the number of bytes written being returned, and not return the false value. In addition to this, the lo resource has been adjusted so that the oid it contains is 0.

Unfortunately, I do not know what exactly the failure mode is, it does seem to be in the ip network communication side of PostgreSQL, which is odd since the unix domain comms works fine for this. However, it would have been useful to have the pg_lo_write() function return as advertised, it would have saved some of the 2 man hours me and the dev. team put into diagnosing this problem.

add a note