3)</literal>
        <returnvalue>\xffaaff</returnvalue>
       </para></entry>
      </row>
     </tbody>
    </tgroup>
   </table>

  <para>
   There are additional server-side functions corresponding to each of the
   client-side functions described earlier; indeed, for the most part the
   client-side functions are simply interfaces to the equivalent server-side
   functions.  The ones just as convenient to call via SQL commands are
   <function>lo_creat</function><indexterm><primary>lo_creat</primary></indexterm>,
   <function>lo_create</function>,
   <function>lo_unlink</function><indexterm><primary>lo_unlink</primary></indexterm>,
   <function>lo_import</function><indexterm><primary>lo_import</primary></indexterm>, and
   <function>lo_export</function><indexterm><primary>lo_export</primary></indexterm>.
   Here are examples of their use:

<programlisting>
CREATE TABLE image (
    name            text,
    raster          oid
);

SELECT lo_creat(-1);       -- returns OID of new, empty large object

SELECT lo_create(43213);   -- attempts to create large object with OID 43213

SELECT lo_unlink(173454);  -- deletes large object with OID 173454

INSERT INTO image (name, raster)
    VALUES ('beautiful image', lo_import('/etc/motd'));

INSERT INTO image (name, raster)  -- same as above, but specify OID to use
    VALUES ('beautiful image', lo_import('/etc/motd', 68583));

SELECT lo_export(image.raster, '/tmp/motd') FROM image
    WHERE name = 'beautiful image';
</programlisting>
  </para>

  <para>
    The server-side <function>lo_import</function> and
    <function>lo_export</function> functions behave considerably differently
    from their client-side analogs.  These two functions read and write files
    in the server's file system, using the permissions of the database's
    owning user.  Therefore, by default their use is restricted to superusers.
    In contrast, the client-side import and export functions read and write
    files in the client's file system, using the permissions of the client
    program.  The client-side functions do not require any database
    privileges, except the privilege to read or write the large object in
    question.
  </para>

  <caution>
   <para>
    It is possible to <xref linkend="sql-grant"/> use of the
    server-side <function>lo_import</function>
    and <function>lo_export</function> functions to non-superusers, but
    careful consideration of the security implications is required.  A
    malicious user of such privileges could easily parlay them into becoming
    superuser (for example by rewriting server configuration files), or could
    attack the rest of the server's file system without bothering to obtain
    database superuser privileges as such.  <emphasis>Access to roles having
    such privilege must therefore be guarded just as carefully as access to
    superuser roles.</emphasis>  Nonetheless, if use of
    server-side <function>lo_import</function>
    or <function>lo_export</function> is needed for some routine task, it's
    safer to use a role with such privileges than one with full superuser
    privileges, as that helps to reduce the risk of damage from accidental
    errors.
   </para>
  </caution>

  <para>
    The functionality of <function>lo_read</function> and
    <function>lo_write</function> is also available via server-side calls,
    but the names of the server-side functions differ from the client side
    interfaces in that they do not contain underscores.  You must call
    these functions as <function>loread</function> and <function>lowrite</function>.
  </para>

</sect1>

<sect1 id="lo-examplesect">
<title>Example Program</title>

<para>
     <xref linkend="lo-example"/> is a sample program which shows how the large object
     interface
     in <application>libpq</application> can be used.  Parts of the program are
     commented out but are left in the source for  the  reader's
     benefit.  This program can also be found in
     <filename>src/test/examples/testlo.c</filename>