35.2. Implementation Features
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.
The chunks stored for a large object do not have to be contiguous. For example, if an application opens a new large object, seeks to offset 1000000, and writes a few bytes there, this does not result in allocation of 1000000 bytes worth of storage; only of chunks covering the range of data bytes actually written. A read operation will, however, read out zeroes for any unallocated locations preceding the last existing chunk. This corresponds to the common behavior of " sparsely allocated " files in Unix file systems.
As of
PostgreSQL
9.0, large objects have an owner
and a set of access permissions, which can be managed using
GRANT
and
REVOKE
.
SELECT
privileges are required to read a large
object, and
UPDATE
privileges are required to write or
truncate it.
Only the large object's owner (or a database superuser) can delete,
comment on, or change the owner of a large object.
To adjust this behavior for compatibility with prior releases, see the
lo_compat_privileges
run-time parameter.