<!--$Header: /cvsroot/pgsql/doc/src/sgml/lobj.sgml,v 1.31.2.1 2003/11/12 20:05:14 petere Exp $--> <chapter id="largeObjects">  <title id="largeObjects-title">Large Objects</title>  <indexterm zone="largeobjects"><primary>large object</></>  <indexterm><primary>BLOB</><see>large object</></>   <para>    In <productname>PostgreSQL</productname> 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, <productname>PostgreSQL</productname>    provided and continues to provide a large object interface.  This    interface provides file-oriented access to user data that is stored in    a special large-object structure.   </para>   <para>    This chapter describes the implementation and the programming and    query language interfaces to <productname>PostgreSQL</productname>    large object data.  We use the <application>libpq</application> C    library for the examples in this chapter, but most programming    interfaces native to <productname>PostgreSQL</productname> support    equivalent functionality.  Other interfaces may use the large    object interface internally to provide generic support for large    values.  This is not described here.   </para>  <sect1 id="lo-history">   <title>History</title>   <para>    <productname>POSTGRES 4.2</productname>, the indirect predecessor    of <productname>PostgreSQL</productname>, supported three standard    implementations of large objects: as files external to the    <productname>POSTGRES</productname> server, as external files    managed by the <productname>POSTGRES</productname> server, and as    data stored within the <productname>POSTGRES</productname>    database. This caused considerable confusion among users. As a    result, only support for large objects as data stored within the    database is retained in <productname>PostgreSQL</productname>.    Even though this is slower to access, it provides stricter data    integrity.  For historical reasons, this storage scheme is    referred to as <firstterm>Inversion large    objects</firstterm>. (You will see the term Inversion used    occasionally to mean the same thing as large object.)  Since    <productname>PostgreSQL 7.1</productname>, all large objects are    placed in one system table called    <classname>pg_largeobject</classname>.   </para>   <para>    <indexterm><primary>TOAST</></>    <indexterm><primary>sliced bread</><see>TOAST</></indexterm>    <productname>PostgreSQL 7.1</productname> introduced a mechanism    (nicknamed <quote><acronym>TOAST</acronym></quote>) 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 values up    to 2 GB in size, whereas <acronym>TOAST</acronym> can only handle 1 GB.   </para>  </sect1>  <sect1 id="lo-implementation">   <title>Implementation Features</title>   <para>    The large object implementation breaks  large    objects  up  into  <quote>chunks</quote>  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.   </para>  </sect1>  <sect1 id="lo-interfaces">   <title>Client Interfaces</title>   <para>    This section describes the facilities that    <productname>PostgreSQL</productname> client interface libraries    provide for accessing large objects.  All large object    manipulation using these functions <emphasis>must</emphasis> take    place within an SQL transaction block.  (This requirement is    strictly enforced as of <productname>PostgreSQL 6.5</>, though it    has been an implicit requirement in previous versions, resulting    in misbehavior if ignored.)    The  <productname>PostgreSQL</productname>  large  object interface is modeled after    the <acronym>Unix</acronym>  file-system  interface,  with  analogues  of    <function>open</function>,  <function>read</function>,    <function>write</function>,    <function>lseek</function>, etc.   </para>   <para>    Client applications which use the large object interface in    <application>libpq</application> should include the header file    <filename>libpq/libpq-fs.h</filename> and link with the    <application>libpq</application> library.   </para>   <sect2>    <title>Creating a Large Object</title>    <para>     The function<synopsis>Oid lo_creat(PGconn *conn, int mode);</synopsis>     <indexterm><primary>lo_creat</></>     creates a new large  object.       <replaceable class="parameter">mode</replaceable>  is  a  bit mask     describing  several  different  attributes  of  the new     object.  The symbolic constants listed here are defined     in the header file <filename>libpq/libpq-fs.h</filename>.     The access type (read, write, or both) is controlled by     or'ing together the bits <symbol>INV_READ</symbol>  and     <symbol>INV_WRITE</symbol>.  The low-order sixteen bits of the mask have     historically been used at Berkeley to designate the storage  manager  number on which the large object     should reside.  These     bits should always be zero now.     The return value is the OID that was assigned to the new large object.    </para>    <para>     An example:<programlisting>inv_oid = lo_creat(INV_READ|INV_WRITE);</programlisting>    </para>   </sect2>   <sect2>    <title>Importing a Large Object</title>    <para>     To import an operating system file as a large object, call<synopsis>Oid lo_import(PGconn *conn, const char *filename);</synopsis>     <indexterm><primary>lo_import</></>     <replaceable class="parameter">filename</replaceable>      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.    </para>   </sect2>   <sect2>    <title>Exporting a Large Object</title>    <para>     To export a large object     into an operating system file, call<synopsis>int lo_export(PGconn *conn, Oid lobjId, const char *filename);</synopsis>     <indexterm><primary>lo_export</></>     The <parameter>lobjId</parameter> argument specifies  the  OID  of  the  large     object  to  export  and the <parameter>filename</parameter> argument specifies     the operating system name name of the file.    </para>   </sect2>   <sect2>    <title>Opening an Existing Large Object</title>    <para>     To open an existing large object, call<synopsis>int lo_open(PGconn *conn, Oid lobjId, int mode);</synopsis>     <indexterm><primary>lo_open</></>     The <parameter>lobjId</parameter> argument specifies  the  OID  of  the  large     object  to  open.   The  <parameter>mode</parameter>  bits control whether the     object is opened  for  reading  (<symbol>INV_READ</>),  writing (<symbol>INV_WRITE</symbol>),  or     both.     A  large  object cannot be opened before it is created.     <function>lo_open</function> returns a large object descriptor     for later use in <function>lo_read</function>, <function>lo_write</function>,     <function>lo_lseek</function>, <function>lo_tell</function>, and     <function>lo_close</function>.  The descriptor is only valid for     the duration of the current transaction.</para></sect2><sect2><title>Writing Data to a Large Object</title><para>     The function<synopsis>int lo_write(PGconn *conn, int fd, const char *buf, size_t len);</synopsis>     <indexterm><primary>lo_write</></> writes     <parameter>len</parameter> bytes from <parameter>buf</parameter>     to large object <parameter>fd</>.  The <parameter>fd</parameter>     argument must have been returned by a previous     <function>lo_open</function>.  The number of bytes actually     written is returned.  In the event of an error, the return value     is negative.</para></sect2><sect2><title>Reading Data from a Large Object</title><para>     The function<synopsis>int lo_read(PGconn *conn, int fd, char *buf, size_t len);</synopsis>     <indexterm><primary>lo_read</></> reads     <parameter>len</parameter> bytes from large object     <parameter>fd</parameter> into <parameter>buf</parameter>. The     <parameter>fd</parameter> argument must have been returned by a     previous <function>lo_open</function>.  The number of bytes     actually read is returned. In the event of an error, the return     value is negative.</para></sect2><sect2><title>Seeking on a Large Object</title><para>     To change the current read or write location on a large     object, call<synopsis>int lo_lseek(PGconn *conn, int fd, int offset, int whence);</synopsis>     <indexterm><primary>lo_lseek</></> This function moves the     current location pointer for the large object described by     <parameter>fd</> to the new location specified by     <parameter>offset</>.  The valid values for <parameter>whence</>     are <symbol>SEEK_SET</> (seek from object start),     <symbol>SEEK_CUR</> (seek from current position), and     <symbol>SEEK_END</> (seek from object end).  The return value is     the new location pointer.</para></sect2><sect2><title>Obtaining the Seek Position of a Large Object</title><para>     To obtain the current read or write location of a large object,     call<synopsis>int lo_tell(PGconn *conn, int fd);</synopsis>     <indexterm><primary>lo_tell</></> If there is an error, the     return value is negative.</para></sect2><sect2><title>Closing a Large Object Descriptor</title><para>     A large object may be closed by calling<synopsis>int lo_close(PGconn *conn, int fd);</synopsis>     <indexterm><primary>lo_close</></> where <parameter>fd</> is a     large object descriptor returned by <function>lo_open</function>.     On success, <function>lo_close</function> returns zero.  On     error, the return value is negative.</para><para>     Any large  object  descriptors that remain open at the end of a     transaction will be closed automatically.</para></sect2>   <sect2>    <title>Removing a Large Object</title>    <para>     To remove a large object from the database, call<synopsis>int lo_unlink(PGconn *conn, Oid lobjId);</synopsis>     <indexterm><primary>lo_unlink</></> The     <parameter>lobjId</parameter> argument specifies the OID of the     large object to remove.  In the event of an error, the return     value is negative.    </para>   </sect2></sect1><sect1 id="lo-funcs"><title>Server-Side Functions</title><para>     There are two built-in server-side functions,     <function>lo_import</function><indexterm><primary>lo_import</></>     and     <function>lo_export</function>,<indexterm><primary>lo_export</></>     for large object access, which are available for use in     <acronym>SQL</acronym> commands.  Here is an example of their