PHP 8.3.4 Released!

pg_lo_write

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

pg_lo_writeWrite to a large object

Description

pg_lo_write(PgSql\Lob $lob, string $data, ?int $length = null): int|false

pg_lo_write() writes data into a large object at the current seek position.

To use the large object interface, it is necessary to enclose it within a transaction block.

Note:

This function used to be called pg_lowrite().

Parameters

lob

An PgSql\Lob instance, returned by pg_lo_open().

data

The data to be written to the large object. If length is an int and is less than the length of data, only length bytes will be written.

length

An optional maximum number of bytes to write. Must be greater than zero and no greater than the length of data. Defaults to the length of data.

Return Values

The number of bytes written to the large object, or false on error.

Changelog

Version Description
8.1.0 The lob parameter expects an PgSql\Lob instance now; previously, a resource was expected.
8.0.0 length is now nullable.

Examples

Example #1 pg_lo_write() example

<?php
$doc_oid
= 189762345;
$data = "This will overwrite the start of the large object.";
$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");
?>

See Also

add a note

User Contributed Notes 2 notes

up
0
cedric at isoca.com
22 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).
up
-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.
To Top