lobj.sgml

关系型数据库 Postgresql 6.5.2

 <chapter id="largeObjects">
  <title id="largeObjects-title">Large Objects</title>

  <para>
   In <productname>Postgres</productname>,
   data values are stored in tuples and 
   individual tuples cannot span data pages. Since the size of
   a data page is 8192 bytes, the upper limit on the  size
   of a data value is relatively low. To support the storage 
   of larger atomic values, 
   <productname>Postgres</productname> provides a  large
   object   interface.    This  interface  provides  file
   oriented access to user data that has been declared  to
   be a large type.
   This  section describes the implementation and the 
   programmatic and query  language  interfaces  to 
   <productname>Postgres</productname>
   large object data.
  </para>

<sect1>
<title>Historical Note</title>

<para>
     Originally, <productname>Postgres 4.2</productname> supported three standard 
     implementations of large objects: as files external 
     to <productname>Postgres</productname>,  as
 <acronym>ym>U</acronym>ym>  files managed by <productname>Postgres</productname>, and as data
     stored within the <productname>Postgres</productname> database. It causes  
     considerable confusion among users. As a result, we only 
     support large objects as data stored within  the  <productname>Postgres</productname>
     database  in  <productname>PostgreSQL</productname>.  Even  though it is slower to
     access, it provides stricter data  integrity.
     For historical reasons, this storage scheme is referred to as 
     Inversion large objects. (We will use  Inversion  and  large
     objects  interchangeably to mean the same thing in this
     section.)
</para>
</sect1>

<sect1>
<title>Inversion Large Objects</title>

<para>
     The Inversion large object implementation breaks  large
     objects  up  into  "chunks"  and  stores  the chunks in
     tuples 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>
<title>Large Object Interfaces</title>

<para>
     The  facilities  <productname>Postgres</productname>  provides  to  access   large
     objects,  both  in  the backend as part of user-defined
     functions or the front end as part  of  an  application
     using  the   interface, are described below. (For users
     familiar with <productname>Postgres 4.2</productname>,
    <productname>PostgreSQL</productname> has a new set of
     functions  providing  a  more  coherent  interface. The
     interface is the same for  dynamically-loaded  C  
     functions as well as for XXX LOST TEXT? WHAT SHOULD GO HERE??.

     The  <productname>Postgres</productname>  large  object interface is modeled after
     the <acronym>UNIX</acronym>  file  system  interface,  with  analogues  of
     <function>open(2)</function>,  <function>read(2)</function>,
<function>write(2)</function>,
 <function>lseek(2)</function>, etc.  User 
     functions call these routines to retrieve only the data  of
     interest  from a large object.  For example, if a large
     object type called mugshot  existed  that  stored  
     photographs  of  faces, then a function called beard could
     be declared on mugshot data.  Beard could look  at  the
     lower third of a photograph, and determine the color of
     the beard that appeared  there,  if  any.   The  entire
     large  object value need not be buffered, or even 
     examined, by the beard function.
     Large objects may be accessed from dynamically-loaded <acronym>C</acronym>
     functions  or  database  client  programs that link the
     library.  <productname>Postgres</productname> provides a set of routines that 
     support opening, reading, writing, closing, and seeking on
     large objects.
</para>

<sect2>
<title>Creating a Large Object</title>

<para>
     The routine
<programlisting>
Oid lo_creat(PGconn *conn, int mode)
</programlisting>
     creates a new large  object.  The  mode  is  a  bitmask
     describing  several  different  attributes  of  the new
     object.  The symbolic constants listed here are defined
     in
<filename>
PGROOT/src/backend/libpq/libpq-fs.h
</filename>
     The access type (read, write, or both) is controlled by
     OR ing together the bits <acronym>INV_READ</acronym>  and
<acronym>INV_WRITE</acronym>.   If
     the large object should be archived -- that is, if 
     historical versions of it should be moved periodically  to
     a  special archive relation -- then the <acronym>INV_ARCHIVE</acronym> bit
     should be set.  The low-order sixteen bits of mask  are
     the  storage  manager  number on which the large object
     should reside.  For sites other  than  Berkeley,  these
     bits should always be zero.
     The commands below create an (Inversion) large object:
<programlisting>
inv_oid = lo_creat(INV_READ|INV_WRITE|INV_ARCHIVE);
</programlisting>
</para>
</sect2>

<sect2>
<title>Importing a Large Object</title>

<para>
To import a <acronym>UNIX</acronym> file as
     a large object, call
<programlisting>
Oid lo_import(PGconn *conn, text *filename)
</programlisting>
     The filename argument specifies the  <acronym>UNIX</acronym>  pathname  of
     the file to be imported as a large object.
</para>
</sect2>

<sect2>
<title>Exporting a Large Object</title>

<para>
To export a large object
     into <acronym>UNIX</acronym> file, call
<programlisting>
int lo_export(PGconn *conn, Oid lobjId, text *filename)
</programlisting>
     The lobjId argument specifies  the  Oid  of  the  large
     object  to  export  and the filename argument specifies
     the <acronym>UNIX</acronym> pathname of the file.
</para>
</sect2>

<sect2>
<title>Opening an Existing Large Object</title>

<para>
     To open an existing large object, call
<programlisting>
int lo_open(PGconn *conn, Oid lobjId, int mode, ...)
</programlisting>
     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  or
     both.
     A  large  object cannot be opened before it is created.
     lo_open returns a large object descriptor for later use
     in  lo_read, lo_write, lo_lseek, lo_tell, and lo_close.
</para>
</sect2>

<sect2>
<title>Writing Data to a Large Object</title>

<para>
     The routine
<programlisting>
int lo_write(PGconn *conn, int fd, char *buf, int len)
</programlisting>
     writes len bytes from buf to large object 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.
</para>
</sect2>

<sect2>
<title>Seeking on a Large Object</title>

<para>
     To change the current read or write location on a large
     object, call
<programlisting>
int lo_lseek(PGconn *conn, int fd, int offset, int whence)
</programlisting>
     This routine moves the current location pointer for the
     large object described by fd to the new location specified 
     by offset.  The valid values  for  .i  whence  are
     SEEK_SET SEEK_CUR and SEEK_END.
</para>
</sect2>

<sect2>
<title>Closing a Large Object Descriptor</title>

<para>
     A large object may be closed by calling
<programlisting>
int lo_close(PGconn *conn, int fd)
</programlisting>
     where  fd  is  a  large  object  descriptor returned by
     lo_open.  On success, <acronym>lo_close</acronym> returns zero.  On error,
     the return value is negative.
</para>
</sect2>
</sect1>

<sect1>
<title>Built in registered functions</title>

<para>
     There  are two built-in registered functions, <acronym>lo_import</acronym>
     and <acronym>lo_export</acronym> which  are  convenient  for  use
    in  <acronym>SQL</acronym>
     queries.
     Here is an example of their use
<programlisting>
CREATE TABLE image (
    name            text,
    raster          oid
);

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

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

<sect1>
<title>Accessing Large Objects from LIBPQ</title>

<para>
     Below is a sample program which shows how the large object  
     interface
     in  LIBPQ  can  be used.  Parts of the program are 
     commented out but are left in the source for  the  readers
     benefit.  This program can be found in
<filename>
../src/test/examples
</filename>
     Frontend applications which use the large object interface  
     in  LIBPQ  should   include   the   header   file
     libpq/libpq-fs.h and link with the libpq library.
</para>
</sect1>

<sect1>
<title>Sample Program</title>