PostgreSQL 7.3.5 Documentation
PrevNext

Chapter 2. Large Objects

Table of Contents
2.1. Introduction
2.2. Implementation Features
2.3. Interfaces
2.3.1. Creating a Large Object
2.3.2. Importing a Large Object
2.3.3. Exporting a Large Object
2.3.4. Opening an Existing Large Object
2.3.5. Writing Data to a Large Object
2.3.6. Reading Data from a Large Object
2.3.7. Seeking on a Large Object
2.3.8. Closing a Large Object Descriptor
2.3.9. Removing a Large Object
2.4. Server-side Built-in Functions
2.5. Accessing Large Objects from Libpq

2.1. Introduction

In PostgreSQL releases prior to 7.1, the size of any row in the database could not exceed the size of a data page. Since the size of a data page is 8192 bytes (the default, which can be raised up to 32768), the upper limit on the size of a data value was relatively low. To support the storage of larger atomic values, PostgreSQL provided and continues to provide a large object interface. This interface provides file-oriented access to user data that has been declared to be a large object.

POSTGRES 4.2, the indirect predecessor of PostgreSQL, supported three standard implementations of large objects: as files external to the POSTGRES server, as external files managed by the POSTGRES server, and as data stored within the POSTGRES database. This caused considerable confusion among users. As a result, only support for large objects as data stored within the database is retained in PostgreSQL. Even though this is slower to access, it provides stricter data integrity. For historical reasons, this storage scheme is referred to as Inversion large objects. (You will see the term Inversion used occasionally to mean the same thing as large object.) Since PostgreSQL 7.1, all large objects are placed in one system table called pg_largeobject.

PostgreSQL 7.1 introduced a mechanism (nicknamed "TOAST") that allows data rows to be much larger than individual data pages. This makes the large object interface partially obsolete. One remaining advantage of the large object interface is that it allows random access to the data, i.e., the ability to read or write small chunks of a large value. It is planned to equip TOAST with such functionality in the future.

This section describes the implementation and the programming and query language interfaces to PostgreSQL large object data. We use the libpq C library for the examples in this section, but most programming interfaces native to PostgreSQL support equivalent functionality. Other interfaces may use the large object interface internally to provide generic support for large values. This is not described here.

PrevHomeNext
Example ProgramsUpImplementation Features