(PHP 5 >= 5.1.2, PHP 7, PECL pdo_pgsql >= 1.0.2)

PDO::pgsqlLOBCreateCreates a new large object


public string PDO::pgsqlLOBCreate ( void )

PDO::pgsqlLOBCreate() creates a large object and returns the OID of that object. You may then open a stream on the object using PDO::pgsqlLOBOpen() to read or write data to it. The OID can be stored in columns of type OID and be used to reference the large object, without causing the row to grow arbitrarily large. The large object will continue to live in the database until it is removed by calling PDO::pgsqlLOBUnlink().

Large objects can be up to 2GB in size, but are cumbersome to use; you need to ensure that PDO::pgsqlLOBUnlink() is called prior to deleting the last row that references its OID from your database. In addition, large objects have no access controls. As an alternative, try the bytea column type; recent versions of PostgreSQL allow bytea columns of up to 1GB in size and transparently manage the storage for optimal row size.

Замечание: This function must be called within a transaction.

Список параметров

PDO::pgsqlLOBCreate() takes no parameters.

Возвращаемые значения

Returns the OID of the newly created large object on success, or FALSE on failure.


Пример #1 A PDO::pgsqlLOBCreate() example

This example creates a new large object and copies the contents of a file into it. The OID is then stored into a table.

= new PDO('pgsql:dbname=test host=localhost'$user$pass);
$oid $db->pgsqlLOBCreate();
$stream $db->pgsqlLOBOpen($oid'w');
$local fopen($filename'rb');
$local null;
$stream null;
$stmt $db->prepare("INSERT INTO BLOBS (ident, oid) VALUES (?, ?)");

Смотрите также

add a note add a note

User Contributed Notes 2 notes

Hayley Watson
1 month ago
If you're not plausibly going to be storing more than 1GB of binary data in a single field, you might as well use the normal bytea type instead of LOBbing it.

They won't bloat the table as PostgreSQL would store the larger byte streams outside the table anyway (as Large Object storage does, only transparently) - including compressing them if it helps - while retaining all the binary string functions and operators.
mauroi at digbang dot com
12 years ago
IMHO, there's a better way to handle the deletion of lob objects than the suggested here. The programmer can easily forget to unlink the lob. With the following trigger, no programmer actions are required.
By the way, one problem with bytea fields is that when you query the database, if you ask for that field, the data is actually retrieved. When you query for and oid, only the oid is retrieved and then you can open the lob whenever you want (if it's required).

CREATE OR REPLACE FUNCTION oidtable_after_update_delete()
  RETURNS "trigger" AS
        IF (OLD.oidfield = NEW.oidfield) OR (OLD.oidfield IS NULL) THEN
           RETURN NEW;
        END IF;
     END IF;
     IF (EXISTS (SELECT 1 FROM pg_largeobject WHERE loid = OLD.oidfield)) THEN
        PERFORM LO_UNLINK (OLD.oidfield);
     END IF;

CREATE TRIGGER oidtable_after_update_delete
  ON oidtable
  EXECUTE PROCEDURE oidtable_after_update_delete();
To Top