Documentation
 
 
 

29.5. Client Interfaces

This section describes the facilities that EnterpriseDB client interface libraries provide for accessing large objects. All large object manipulation using these functions must take place within an SQL transaction block. The EnterpriseDB large object interface is modeled after the UNIX file-system interface, with analogues of operations like open, read, write, lseek, etc.

Client applications which use the large object interface in libpq should include the header file libpq/libpq-fs.h and link with the libpq library.

29.5.1. What are Large Objects?

All large objects are placed in a single system table called pg_largeobject. EnterpriseDB also supports a storage system called "TOAST" that automatically stores values larger than a single database page into a secondary storage area per table. This makes the large object facility partially obsolete.

One remaining advantage of the large object facility is that it allows values up to 2 GB in size, whereas TOAST table fields can be at most 1 GB. Also, large objects can be randomly modified using a read/write API that is more efficient than performing such operations using TOAST.

The large object implementation breaks large objects up into "chunks" and stores the chunks in rows in the database. A B-tree index guarantees fast searches for the correct chunk number when doing random access reads and writes.

EnterpriseDB has a large object facility, which provides stream-style access to user data that is stored in a special large-object structure. Streaming access is useful when working with data values that are too large to manipulate conveniently as a whole.

The following sections explain the various concepts related to the usage of a large object in a libpq application.

29.5.2. Creating a Large Object

Oid lo_creat(PGconn *conn, int mode);

The above function creates a new large object. The return value is the OID that was assigned to the new large object, or InvalidOid (zero) on failure. The parameter mode is unused and ignored for current versions of EnterpriseDB; however, for backwards compatibility with earlier releases it is best to set it to INV_READ, INV_WRITE, or INV_READ | INV_WRITE. (These symbolic constants are defined in the header file libpq/libpq-fs.h.)

The following example illustrates the usage of the above symbolic constants:

inv_oid = lo_creat(conn, INV_READ|INV_WRITE);

Oid lo_create(PGconn *conn, Oid lobjId);

The above function also creates a new large object. The OID to be assigned can be specified by lobjId; if so, failure occurs if that OID is already in use for some large object. If lobjId is InvalidOid (zero) then lo_create assigns an unused OID (this is the same behavior as lo_creat). The return value is the OID that was assigned to the new large object, or InvalidOid (zero) on failure.

lo_create is new function and if this function is run against an older server version, it will fail and return InvalidOid.

The following example illustrates the usage:

inv_oid = lo_create(conn, desired_oid);

29.5.3. Importing a Large Object

To import an operating system file as a large object, the user needs to call the following function:

Oid lo_import(PGconn *conn, const char *filename);

The parameter filename specifies the operating system name of the file to be imported as a large object. The return value is the OID that was assigned to the new large object, or InvalidOid (zero) on failure.

Note: Note that the file is read by the client interface library, not by the server; so it must exist in the client file system and be readable by the client application.

29.5.4. Exporting a Large Object

To export a large object into an operating system file, the user needs to call the following function:

int lo_export(PGconn *conn, Oid lobjId, const char *filename);

The lobjId argument specifies the OID of the large object to export and the filename argument specifies the operating system name of the file.

Note: Note that the file is written by the client interface library, not by the server. Returns 1 on success, -1 on failure.

29.5.5. Opening an Existing Large Object

In order to open an existing large object for reading or writing, the user needs to call the following function:

int lo_open(PGconn *conn, Oid lobjId, int mode);

The lobjId argument specifies the OID of the large object to open. The mode bits control whether the object is opened for reading (INV_READ), writing (INV_WRITE), or both. A large object cannot be opened before it is created. lo_open returns a (non-negative) large object descriptor for later use in lo_read, lo_write, lo_lseek, lo_tell, and lo_close. The descriptor is only valid for the duration of the current transaction. On failure, -1 is returned.

The server currently does not distinguish between modes INV_WRITE and INV_READ | INV_WRITE: you are allowed to read from the descriptor in either case. However there is a significant difference between these modes and INV_READ alone: with INV_READ you cannot write on the descriptor, and the data read from it will reflect the contents of the large object at the time of the transaction snapshot that was active when lo_open was executed, regardless of later writes by this or other transactions. Reading from a descriptor opened with INV_WRITE returns data that reflects all writes of other committed transactions as well as writes of the current transaction. This is similar to the behavior of SERIALIZABLE versus READ COMMITTED transaction modes for ordinary SQL SELECT commands.

An example:

inv_fd = lo_open(conn, inv_oid, INV_READ|INV_WRITE);

29.5.6. Writing Data to a Large Object

int lo_write(PGconn *conn, int fd, const char *buf, size_t len);

The above function writes len bytes from buf to large object descriptor fd. The fd argument must have been returned by a previous lo_open. The number of bytes actually written is returned. In the event of an error, the return value is negative.

29.5.7. Reading Data from a Large Object

int lo_read(PGconn *conn, int fd, char *buf, size_t len);

The above function reads len bytes from large object descriptor fd into buf. The fd argument must have been returned by a previous lo_open. The number of bytes actually read is returned. In the event of an error, the return value is negative.

29.5.8. Seeking in a Large Object

To change the current read or write location associated with a large object descriptor, the user needs to call the following function:

int lo_lseek(PGconn *conn, int fd, int offset, int whence);

This function moves the current location pointer for the large object descriptor identified by fd to the new location specified by offset. The valid values for whence are SEEK_SET (seek from object start), SEEK_CUR (seek from current position), and SEEK_END (seek from object end). The return value is the new location pointer, or -1 on error.

29.5.9. Obtaining the Seek Position of a Large Object

To obtain the current read or write location of a large object descriptor, the user needs to call the following function:

int lo_tell(PGconn *conn, int fd);

If there is an error, the return value is negative.

29.5.10. Closing a Large Object Descriptor

A large object descriptor may be closed by calling the following function:

int lo_close(PGconn *conn, int fd);

where fd is a large object descriptor returned by lo_open. On success, lo_close returns zero. On error, the return value is negative.

Any large object descriptors that remain open at the end of a transaction will be closed automatically.

29.5.11. Removing a Large Object

To remove a large object from the database, the user needs to call the following function:

int lo_unlink(PGconn *conn, Oid lobjId);

The lobjId argument specifies the OID of the large object to remove. Returns 1 if successful, -1 on failure.

 
 ©2004-2007 EnterpriseDB All Rights Reserved