2010-09-20 22:08:53 +02:00
|
|
|
<!-- doc/src/sgml/lobj.sgml -->
|
2000-03-31 05:27:42 +02:00
|
|
|
|
2017-10-20 03:16:39 +02:00
|
|
|
<chapter id="largeobjects">
|
2010-04-03 09:23:02 +02:00
|
|
|
<title>Large Objects</title>
|
1999-06-14 09:36:12 +02:00
|
|
|
|
2017-10-09 03:44:17 +02:00
|
|
|
<indexterm zone="largeobjects"><primary>large object</primary></indexterm>
|
|
|
|
<indexterm><primary>BLOB</primary><see>large object</see></indexterm>
|
2001-11-12 20:19:39 +01:00
|
|
|
|
1999-10-04 17:18:54 +02:00
|
|
|
<para>
|
2017-10-09 03:44:17 +02:00
|
|
|
<productname>PostgreSQL</productname> has a <firstterm>large object</firstterm>
|
2004-12-28 23:47:15 +01:00
|
|
|
facility, which provides stream-style access to user data that is stored
|
|
|
|
in a special large-object structure. Streaming access is useful
|
|
|
|
when working with data values that are too large to manipulate
|
|
|
|
conveniently as a whole.
|
1999-10-04 17:18:54 +02:00
|
|
|
</para>
|
2001-09-17 00:53:52 +02:00
|
|
|
|
2003-03-13 02:30:29 +01:00
|
|
|
<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
|
Update documentation on may/can/might:
Standard English uses "may", "can", and "might" in different ways:
may - permission, "You may borrow my rake."
can - ability, "I can lift that log."
might - possibility, "It might rain today."
Unfortunately, in conversational English, their use is often mixed, as
in, "You may use this variable to do X", when in fact, "can" is a better
choice. Similarly, "It may crash" is better stated, "It might crash".
Also update two error messages mentioned in the documenation to match.
2007-01-31 21:56:20 +01:00
|
|
|
equivalent functionality. Other interfaces might use the large
|
2003-03-13 02:30:29 +01:00
|
|
|
object interface internally to provide generic support for large
|
|
|
|
values. This is not described here.
|
|
|
|
</para>
|
|
|
|
|
2006-04-23 05:39:52 +02:00
|
|
|
<sect1 id="lo-intro">
|
|
|
|
<title>Introduction</title>
|
2003-03-13 02:30:29 +01:00
|
|
|
|
2006-04-23 05:39:52 +02:00
|
|
|
<indexterm>
|
|
|
|
<primary>TOAST</primary>
|
|
|
|
<secondary>versus large objects</secondary>
|
|
|
|
</indexterm>
|
2001-09-17 00:53:52 +02:00
|
|
|
|
|
|
|
<para>
|
2012-10-08 01:16:28 +02:00
|
|
|
All large objects are stored in a single system table named <link
|
|
|
|
linkend="catalog-pg-largeobject"><structname>pg_largeobject</structname></link>.
|
|
|
|
Each large object also has an entry in the system table <link
|
|
|
|
linkend="catalog-pg-largeobject-metadata"><structname>pg_largeobject_metadata</structname></link>.
|
|
|
|
Large objects can be created, modified, and deleted using a read/write API
|
|
|
|
that is similar to standard operations on files.
|
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
2006-04-23 05:39:52 +02:00
|
|
|
<productname>PostgreSQL</productname> also supports a storage system called
|
2012-10-08 01:16:28 +02:00
|
|
|
<link
|
|
|
|
linkend="storage-toast"><quote><acronym>TOAST</acronym></quote></link>,
|
|
|
|
which automatically stores values
|
2006-04-23 05:39:52 +02:00
|
|
|
larger than a single database page into a secondary storage area per table.
|
|
|
|
This makes the large object facility partially obsolete. One
|
2004-12-28 23:47:15 +01:00
|
|
|
remaining advantage of the large object facility is that it allows values
|
2016-08-05 20:35:09 +02:00
|
|
|
up to 4 TB in size, whereas <acronym>TOAST</acronym>ed fields can be at
|
|
|
|
most 1 GB. Also, reading and updating portions of a large object can be
|
2012-10-08 01:16:28 +02:00
|
|
|
done efficiently, while most operations on a <acronym>TOAST</acronym>ed
|
|
|
|
field will read or write the whole value as a unit.
|
2001-09-17 00:53:52 +02:00
|
|
|
</para>
|
|
|
|
|
1999-10-04 17:18:54 +02:00
|
|
|
</sect1>
|
|
|
|
|
2000-09-29 22:21:34 +02:00
|
|
|
<sect1 id="lo-implementation">
|
1999-10-04 17:18:54 +02:00
|
|
|
<title>Implementation Features</title>
|
|
|
|
|
|
|
|
<para>
|
2006-04-23 05:39:52 +02:00
|
|
|
The large object implementation breaks large
|
|
|
|
objects up into <quote>chunks</quote> and stores the chunks in
|
2003-03-13 02:30:29 +01:00
|
|
|
rows in the database. A B-tree index guarantees fast
|
1999-10-04 17:18:54 +02:00
|
|
|
searches for the correct chunk number when doing random
|
|
|
|
access reads and writes.
|
|
|
|
</para>
|
2009-12-17 15:36:16 +01:00
|
|
|
|
2012-10-09 03:12:27 +02:00
|
|
|
<para>
|
|
|
|
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.
|
2017-10-09 03:44:17 +02:00
|
|
|
This corresponds to the common behavior of <quote>sparsely allocated</quote>
|
2012-10-09 03:12:27 +02:00
|
|
|
files in <acronym>Unix</acronym> file systems.
|
|
|
|
</para>
|
|
|
|
|
2009-12-17 15:36:16 +01:00
|
|
|
<para>
|
2017-10-09 03:44:17 +02:00
|
|
|
As of <productname>PostgreSQL</productname> 9.0, large objects have an owner
|
2009-12-17 15:36:16 +01:00
|
|
|
and a set of access permissions, which can be managed using
|
2017-11-23 15:39:47 +01:00
|
|
|
<xref linkend="sql-grant"/> and
|
|
|
|
<xref linkend="sql-revoke"/>.
|
2009-12-17 15:36:16 +01:00
|
|
|
<literal>SELECT</literal> privileges are required to read a large
|
2010-11-23 21:27:50 +01:00
|
|
|
object, and
|
2012-10-08 01:16:28 +02:00
|
|
|
<literal>UPDATE</literal> privileges are required to write or
|
2009-12-17 15:36:16 +01:00
|
|
|
truncate it.
|
2012-10-08 01:16:28 +02:00
|
|
|
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
|
2017-11-23 15:39:47 +01:00
|
|
|
<xref linkend="guc-lo-compat-privileges"/> run-time parameter.
|
2009-12-17 15:36:16 +01:00
|
|
|
</para>
|
1999-10-04 17:18:54 +02:00
|
|
|
</sect1>
|
|
|
|
|
2000-09-29 22:21:34 +02:00
|
|
|
<sect1 id="lo-interfaces">
|
2003-03-13 02:30:29 +01:00
|
|
|
<title>Client Interfaces</title>
|
1999-10-04 17:18:54 +02:00
|
|
|
|
|
|
|
<para>
|
2003-03-13 02:30:29 +01:00
|
|
|
This section describes the facilities that
|
2017-10-09 03:44:17 +02:00
|
|
|
<productname>PostgreSQL</productname>'s <application>libpq</application>
|
2012-10-08 01:16:28 +02:00
|
|
|
client interface library provides for accessing large objects.
|
|
|
|
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>,
|
2003-03-13 02:30:29 +01:00
|
|
|
<function>write</function>,
|
|
|
|
<function>lseek</function>, etc.
|
1999-10-04 17:18:54 +02:00
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
2012-10-08 01:16:28 +02:00
|
|
|
All large object manipulation using these functions
|
|
|
|
<emphasis>must</emphasis> take place within an SQL transaction block,
|
|
|
|
since large object file descriptors are only valid for the duration of
|
|
|
|
a transaction.
|
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
If an error occurs while executing any one of these functions, the
|
|
|
|
function will return an otherwise-impossible value, typically 0 or -1.
|
|
|
|
A message describing the error is stored in the connection object and
|
2019-07-25 17:23:36 +02:00
|
|
|
can be retrieved with <xref linkend="libpq-PQerrorMessage"/>.
|
2012-10-08 01:16:28 +02:00
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
Client applications that use these functions should include the header file
|
2003-03-13 02:30:29 +01:00
|
|
|
<filename>libpq/libpq-fs.h</filename> and link with the
|
|
|
|
<application>libpq</application> library.
|
1999-10-04 17:18:54 +02:00
|
|
|
</para>
|
|
|
|
|
2021-03-15 22:13:42 +01:00
|
|
|
<para>
|
|
|
|
Client applications cannot use these functions while a libpq connection is in pipeline mode.
|
|
|
|
</para>
|
|
|
|
|
2010-08-10 04:56:46 +02:00
|
|
|
<sect2 id="lo-create">
|
1999-10-04 17:18:54 +02:00
|
|
|
<title>Creating a Large Object</title>
|
|
|
|
|
|
|
|
<para>
|
2022-02-01 16:57:26 +01:00
|
|
|
<indexterm><primary>lo_create</primary></indexterm>
|
2003-03-13 02:30:29 +01:00
|
|
|
The function
|
1999-11-11 22:52:28 +01:00
|
|
|
<synopsis>
|
2022-02-01 16:57:26 +01:00
|
|
|
Oid lo_create(PGconn *conn, Oid lobjId);
|
1999-11-11 22:52:28 +01:00
|
|
|
</synopsis>
|
2022-02-01 16:57:26 +01:00
|
|
|
creates a new large object. The OID to be assigned can be
|
|
|
|
specified by <replaceable class="parameter">lobjId</replaceable>;
|
|
|
|
if so, failure occurs if that OID is already in use for some large
|
|
|
|
object. If <replaceable class="parameter">lobjId</replaceable>
|
|
|
|
is <symbol>InvalidOid</symbol> (zero) then <function>lo_create</function>
|
|
|
|
assigns an unused OID.
|
2005-01-08 23:13:38 +01:00
|
|
|
The return value is the OID that was assigned to the new large object,
|
2006-10-23 20:10:32 +02:00
|
|
|
or <symbol>InvalidOid</symbol> (zero) on failure.
|
2003-03-13 02:30:29 +01:00
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
An example:
|
2001-09-17 00:53:52 +02:00
|
|
|
<programlisting>
|
2022-02-01 16:57:26 +01:00
|
|
|
inv_oid = lo_create(conn, desired_oid);
|
2005-06-13 04:26:53 +02:00
|
|
|
</programlisting>
|
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
2022-02-01 16:57:26 +01:00
|
|
|
<indexterm><primary>lo_creat</primary></indexterm>
|
|
|
|
The older function
|
2005-06-13 04:26:53 +02:00
|
|
|
<synopsis>
|
2022-02-01 16:57:26 +01:00
|
|
|
Oid lo_creat(PGconn *conn, int mode);
|
2005-06-13 04:26:53 +02:00
|
|
|
</synopsis>
|
2022-02-01 16:57:26 +01:00
|
|
|
also creates a new large object, always assigning an unused OID.
|
2005-06-13 04:26:53 +02:00
|
|
|
The return value is the OID that was assigned to the new large object,
|
2006-10-23 20:10:32 +02:00
|
|
|
or <symbol>InvalidOid</symbol> (zero) on failure.
|
2005-06-13 04:26:53 +02:00
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
2022-02-01 16:57:26 +01:00
|
|
|
In <productname>PostgreSQL</productname> releases 8.1 and later,
|
|
|
|
the <replaceable class="parameter">mode</replaceable> is ignored,
|
|
|
|
so that <function>lo_creat</function> is exactly equivalent to
|
|
|
|
<function>lo_create</function> with a zero second argument.
|
|
|
|
However, there is little reason to use <function>lo_creat</function>
|
|
|
|
unless you need to work with servers older than 8.1.
|
|
|
|
To work with such an old server, you must
|
|
|
|
use <function>lo_creat</function> not <function>lo_create</function>,
|
|
|
|
and you must set <replaceable class="parameter">mode</replaceable> to
|
|
|
|
one of <symbol>INV_READ</symbol>, <symbol>INV_WRITE</symbol>,
|
|
|
|
or <symbol>INV_READ</symbol> <literal>|</literal> <symbol>INV_WRITE</symbol>.
|
|
|
|
(These symbolic constants are defined
|
|
|
|
in the header file <filename>libpq/libpq-fs.h</filename>.)
|
2005-06-13 04:26:53 +02:00
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
An example:
|
|
|
|
<programlisting>
|
2022-02-01 16:57:26 +01:00
|
|
|
inv_oid = lo_creat(conn, INV_READ|INV_WRITE);
|
2001-09-17 00:53:52 +02:00
|
|
|
</programlisting>
|
1999-10-04 17:18:54 +02:00
|
|
|
</para>
|
|
|
|
</sect2>
|
|
|
|
|
2010-08-09 14:00:24 +02:00
|
|
|
<sect2 id="lo-import">
|
1999-10-04 17:18:54 +02:00
|
|
|
<title>Importing a Large Object</title>
|
|
|
|
|
|
|
|
<para>
|
2017-10-09 03:44:17 +02:00
|
|
|
<indexterm><primary>lo_import</primary></indexterm>
|
2002-01-07 03:29:15 +01:00
|
|
|
To import an operating system file as a large object, call
|
1999-11-11 22:52:28 +01:00
|
|
|
<synopsis>
|
2003-03-13 02:30:29 +01:00
|
|
|
Oid lo_import(PGconn *conn, const char *filename);
|
1999-11-11 22:52:28 +01:00
|
|
|
</synopsis>
|
2010-11-23 21:27:50 +01:00
|
|
|
<replaceable class="parameter">filename</replaceable>
|
2002-01-07 03:29:15 +01:00
|
|
|
specifies the operating system name of
|
1998-03-01 09:16:16 +01:00
|
|
|
the file to be imported as a large object.
|
2005-01-08 23:13:38 +01:00
|
|
|
The return value is the OID that was assigned to the new large object,
|
2006-10-23 20:10:32 +02:00
|
|
|
or <symbol>InvalidOid</symbol> (zero) on failure.
|
2004-12-28 23:47:15 +01:00
|
|
|
Note that the file is read by the client interface library, not by
|
2006-10-23 20:10:32 +02:00
|
|
|
the server; so it must exist in the client file system and be readable
|
2004-12-28 23:47:15 +01:00
|
|
|
by the client application.
|
1999-10-04 17:18:54 +02:00
|
|
|
</para>
|
2008-03-19 01:39:33 +01:00
|
|
|
|
|
|
|
<para>
|
2017-10-09 03:44:17 +02:00
|
|
|
<indexterm><primary>lo_import_with_oid</primary></indexterm>
|
2008-03-19 01:39:33 +01:00
|
|
|
The function
|
|
|
|
<synopsis>
|
|
|
|
Oid lo_import_with_oid(PGconn *conn, const char *filename, Oid lobjId);
|
|
|
|
</synopsis>
|
|
|
|
also imports a new large object. The OID to be assigned can be
|
|
|
|
specified by <replaceable class="parameter">lobjId</replaceable>;
|
|
|
|
if so, failure occurs if that OID is already in use for some large
|
|
|
|
object. If <replaceable class="parameter">lobjId</replaceable>
|
2017-10-09 03:44:17 +02:00
|
|
|
is <symbol>InvalidOid</symbol> (zero) then <function>lo_import_with_oid</function> assigns an unused
|
|
|
|
OID (this is the same behavior as <function>lo_import</function>).
|
2008-03-19 01:39:33 +01:00
|
|
|
The return value is the OID that was assigned to the new large object,
|
|
|
|
or <symbol>InvalidOid</symbol> (zero) on failure.
|
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
2017-10-09 03:44:17 +02:00
|
|
|
<function>lo_import_with_oid</function> is new as of <productname>PostgreSQL</productname>
|
2008-03-19 01:39:33 +01:00
|
|
|
8.4 and uses <function>lo_create</function> internally which is new in 8.1; if this function is run against 8.0 or before, it will
|
|
|
|
fail and return <symbol>InvalidOid</symbol>.
|
|
|
|
</para>
|
1999-10-04 17:18:54 +02:00
|
|
|
</sect2>
|
|
|
|
|
2010-08-09 14:00:24 +02:00
|
|
|
<sect2 id="lo-export">
|
1999-10-04 17:18:54 +02:00
|
|
|
<title>Exporting a Large Object</title>
|
|
|
|
|
|
|
|
<para>
|
2017-10-09 03:44:17 +02:00
|
|
|
<indexterm><primary>lo_export</primary></indexterm>
|
1999-10-04 17:18:54 +02:00
|
|
|
To export a large object
|
2002-01-07 03:29:15 +01:00
|
|
|
into an operating system file, call
|
1999-11-11 22:52:28 +01:00
|
|
|
<synopsis>
|
2003-03-13 02:30:29 +01:00
|
|
|
int lo_export(PGconn *conn, Oid lobjId, const char *filename);
|
1999-11-11 22:52:28 +01:00
|
|
|
</synopsis>
|
2005-01-08 23:13:38 +01:00
|
|
|
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 of the file. Note that the file is
|
|
|
|
written by the client interface library, not by the server. Returns 1
|
|
|
|
on success, -1 on failure.
|
1999-10-04 17:18:54 +02:00
|
|
|
</para>
|
|
|
|
</sect2>
|
1998-03-01 09:16:16 +01:00
|
|
|
|
2010-08-09 14:00:24 +02:00
|
|
|
<sect2 id="lo-open">
|
1999-10-04 17:18:54 +02:00
|
|
|
<title>Opening an Existing Large Object</title>
|
1998-03-01 09:16:16 +01:00
|
|
|
|
1999-10-04 17:18:54 +02:00
|
|
|
<para>
|
2017-10-09 03:44:17 +02:00
|
|
|
<indexterm><primary>lo_open</primary></indexterm>
|
2005-01-08 23:13:38 +01:00
|
|
|
To open an existing large object for reading or writing, call
|
1999-11-11 22:52:28 +01:00
|
|
|
<synopsis>
|
2003-03-13 02:30:29 +01:00
|
|
|
int lo_open(PGconn *conn, Oid lobjId, int mode);
|
1999-11-11 22:52:28 +01:00
|
|
|
</synopsis>
|
2005-06-13 04:26:53 +02:00
|
|
|
The <parameter>lobjId</parameter> argument specifies the OID of the large
|
|
|
|
object to open. The <parameter>mode</parameter> bits control whether the
|
2017-10-09 03:44:17 +02:00
|
|
|
object is opened for reading (<symbol>INV_READ</symbol>), writing
|
2005-06-13 04:26:53 +02:00
|
|
|
(<symbol>INV_WRITE</symbol>), or both.
|
|
|
|
(These symbolic constants are defined
|
|
|
|
in the header file <filename>libpq/libpq-fs.h</filename>.)
|
2005-01-08 23:13:38 +01:00
|
|
|
<function>lo_open</function> returns a (non-negative) large object
|
|
|
|
descriptor for later use in <function>lo_read</function>,
|
|
|
|
<function>lo_write</function>, <function>lo_lseek</function>,
|
2012-10-08 01:16:28 +02:00
|
|
|
<function>lo_lseek64</function>, <function>lo_tell</function>,
|
2012-10-07 01:36:48 +02:00
|
|
|
<function>lo_tell64</function>, <function>lo_truncate</function>,
|
2012-10-08 01:16:28 +02:00
|
|
|
<function>lo_truncate64</function>, and <function>lo_close</function>.
|
2010-11-23 21:27:50 +01:00
|
|
|
The descriptor is only valid for
|
2003-06-21 23:51:35 +02:00
|
|
|
the duration of the current transaction.
|
2005-01-08 23:13:38 +01:00
|
|
|
On failure, -1 is returned.
|
2005-06-13 04:26:53 +02:00
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
The server currently does not distinguish between modes
|
2017-10-09 03:44:17 +02:00
|
|
|
<symbol>INV_WRITE</symbol> and <symbol>INV_READ</symbol> <literal>|</literal>
|
2005-06-13 04:26:53 +02:00
|
|
|
<symbol>INV_WRITE</symbol>: you are allowed to read from the descriptor
|
|
|
|
in either case. However there is a significant difference between
|
2017-10-09 03:44:17 +02:00
|
|
|
these modes and <symbol>INV_READ</symbol> alone: with <symbol>INV_READ</symbol>
|
2005-06-13 04:26:53 +02:00
|
|
|
you cannot write on the descriptor, and the data read from it will
|
|
|
|
reflect the contents of the large object at the time of the transaction
|
2017-10-09 03:44:17 +02:00
|
|
|
snapshot that was active when <function>lo_open</function> was executed,
|
2005-06-13 04:26:53 +02:00
|
|
|
regardless of later writes by this or other transactions. Reading
|
|
|
|
from a descriptor opened with <symbol>INV_WRITE</symbol> returns
|
|
|
|
data that reflects all writes of other committed transactions as well
|
|
|
|
as writes of the current transaction. This is similar to the behavior
|
2017-10-09 03:44:17 +02:00
|
|
|
of <literal>REPEATABLE READ</literal> versus <literal>READ COMMITTED</literal> transaction
|
|
|
|
modes for ordinary SQL <command>SELECT</command> commands.
|
2005-06-13 04:26:53 +02:00
|
|
|
</para>
|
|
|
|
|
2017-11-14 18:33:10 +01:00
|
|
|
<para>
|
|
|
|
<function>lo_open</function> will fail if <literal>SELECT</literal>
|
|
|
|
privilege is not available for the large object, or
|
|
|
|
if <symbol>INV_WRITE</symbol> is specified and <literal>UPDATE</literal>
|
|
|
|
privilege is not available.
|
|
|
|
(Prior to <productname>PostgreSQL</productname> 11, these privilege
|
|
|
|
checks were instead performed at the first actual read or write call
|
|
|
|
using the descriptor.)
|
|
|
|
These privilege checks can be disabled with the
|
2017-11-23 15:39:47 +01:00
|
|
|
<xref linkend="guc-lo-compat-privileges"/> run-time parameter.
|
2017-11-14 18:33:10 +01:00
|
|
|
</para>
|
|
|
|
|
2005-06-13 04:26:53 +02:00
|
|
|
<para>
|
|
|
|
An example:
|
|
|
|
<programlisting>
|
|
|
|
inv_fd = lo_open(conn, inv_oid, INV_READ|INV_WRITE);
|
|
|
|
</programlisting>
|
|
|
|
</para>
|
1999-06-14 09:36:12 +02:00
|
|
|
</sect2>
|
1998-03-01 09:16:16 +01:00
|
|
|
|
2010-08-09 14:00:24 +02:00
|
|
|
<sect2 id="lo-write">
|
1999-06-14 09:36:12 +02:00
|
|
|
<title>Writing Data to a Large Object</title>
|
1998-03-01 09:16:16 +01:00
|
|
|
|
1999-06-14 09:36:12 +02:00
|
|
|
<para>
|
2017-10-09 03:44:17 +02:00
|
|
|
<indexterm><primary>lo_write</primary></indexterm>
|
2003-03-13 02:30:29 +01:00
|
|
|
The function
|
|
|
|
<synopsis>
|
|
|
|
int lo_write(PGconn *conn, int fd, const char *buf, size_t len);
|
|
|
|
</synopsis>
|
2012-10-08 01:16:28 +02:00
|
|
|
writes <parameter>len</parameter> bytes from <parameter>buf</parameter>
|
2012-10-09 03:12:27 +02:00
|
|
|
(which must be of size <parameter>len</parameter>) to large object
|
2017-10-09 03:44:17 +02:00
|
|
|
descriptor <parameter>fd</parameter>. The <parameter>fd</parameter> argument must
|
2012-10-09 03:12:27 +02:00
|
|
|
have been returned by a previous <function>lo_open</function>. The
|
|
|
|
number of bytes actually written is returned (in the current
|
|
|
|
implementation, this will always equal <parameter>len</parameter> unless
|
|
|
|
there is an error). In the event of an error, the return value is -1.
|
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
Although the <parameter>len</parameter> parameter is declared as
|
2017-10-09 03:44:17 +02:00
|
|
|
<type>size_t</type>, this function will reject length values larger than
|
|
|
|
<literal>INT_MAX</literal>. In practice, it's best to transfer data in chunks
|
2012-10-09 03:12:27 +02:00
|
|
|
of at most a few megabytes anyway.
|
1999-06-14 09:36:12 +02:00
|
|
|
</para>
|
|
|
|
</sect2>
|
1998-03-01 09:16:16 +01:00
|
|
|
|
2010-08-09 14:00:24 +02:00
|
|
|
<sect2 id="lo-read">
|
1999-11-11 22:52:28 +01:00
|
|
|
<title>Reading Data from a Large Object</title>
|
|
|
|
|
|
|
|
<para>
|
2017-10-09 03:44:17 +02:00
|
|
|
<indexterm><primary>lo_read</primary></indexterm>
|
2003-03-13 02:30:29 +01:00
|
|
|
The function
|
|
|
|
<synopsis>
|
|
|
|
int lo_read(PGconn *conn, int fd, char *buf, size_t len);
|
|
|
|
</synopsis>
|
2012-10-09 03:12:27 +02:00
|
|
|
reads up to <parameter>len</parameter> bytes from large object descriptor
|
|
|
|
<parameter>fd</parameter> into <parameter>buf</parameter> (which must be
|
|
|
|
of size <parameter>len</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; this will be less than <parameter>len</parameter> if the end of
|
|
|
|
the large object is reached first. In the event of an error, the return
|
2012-10-08 01:16:28 +02:00
|
|
|
value is -1.
|
1999-11-11 22:52:28 +01:00
|
|
|
</para>
|
2012-10-09 03:12:27 +02:00
|
|
|
|
|
|
|
<para>
|
|
|
|
Although the <parameter>len</parameter> parameter is declared as
|
2017-10-09 03:44:17 +02:00
|
|
|
<type>size_t</type>, this function will reject length values larger than
|
|
|
|
<literal>INT_MAX</literal>. In practice, it's best to transfer data in chunks
|
2012-10-09 03:12:27 +02:00
|
|
|
of at most a few megabytes anyway.
|
|
|
|
</para>
|
1999-11-11 22:52:28 +01:00
|
|
|
</sect2>
|
|
|
|
|
2010-08-09 14:00:24 +02:00
|
|
|
<sect2 id="lo-seek">
|
2004-12-28 23:47:15 +01:00
|
|
|
<title>Seeking in a Large Object</title>
|
1998-03-01 09:16:16 +01:00
|
|
|
|
1999-06-14 09:36:12 +02:00
|
|
|
<para>
|
2017-10-09 03:44:17 +02:00
|
|
|
<indexterm><primary>lo_lseek</primary></indexterm>
|
2004-12-28 23:47:15 +01:00
|
|
|
To change the current read or write location associated with a
|
|
|
|
large object descriptor, call
|
2003-03-13 02:30:29 +01:00
|
|
|
<synopsis>
|
|
|
|
int lo_lseek(PGconn *conn, int fd, int offset, int whence);
|
|
|
|
</synopsis>
|
2012-10-08 01:16:28 +02:00
|
|
|
This function moves the
|
2004-12-28 23:47:15 +01:00
|
|
|
current location pointer for the large object descriptor identified by
|
2017-10-09 03:44:17 +02:00
|
|
|
<parameter>fd</parameter> to the new location specified by
|
|
|
|
<parameter>offset</parameter>. The valid values for <parameter>whence</parameter>
|
|
|
|
are <symbol>SEEK_SET</symbol> (seek from object start),
|
|
|
|
<symbol>SEEK_CUR</symbol> (seek from current position), and
|
|
|
|
<symbol>SEEK_END</symbol> (seek from object end). The return value is
|
2005-01-08 23:13:38 +01:00
|
|
|
the new location pointer, or -1 on error.
|
2003-03-13 02:30:29 +01:00
|
|
|
</para>
|
2012-10-08 01:16:28 +02:00
|
|
|
|
|
|
|
<para>
|
2017-10-09 03:44:17 +02:00
|
|
|
<indexterm><primary>lo_lseek64</primary></indexterm>
|
2012-10-08 01:16:28 +02:00
|
|
|
When dealing with large objects that might exceed 2GB in size,
|
|
|
|
instead use
|
|
|
|
<synopsis>
|
|
|
|
pg_int64 lo_lseek64(PGconn *conn, int fd, pg_int64 offset, int whence);
|
|
|
|
</synopsis>
|
|
|
|
This function has the same behavior
|
|
|
|
as <function>lo_lseek</function>, but it can accept an
|
2017-10-09 03:44:17 +02:00
|
|
|
<parameter>offset</parameter> larger than 2GB and/or deliver a result larger
|
2012-10-08 01:16:28 +02:00
|
|
|
than 2GB.
|
|
|
|
Note that <function>lo_lseek</function> will fail if the new location
|
|
|
|
pointer would be greater than 2GB.
|
|
|
|
</para>
|
|
|
|
|
2012-10-07 01:36:48 +02:00
|
|
|
<para>
|
2017-10-09 03:44:17 +02:00
|
|
|
<function>lo_lseek64</function> is new as of <productname>PostgreSQL</productname>
|
2012-10-08 01:16:28 +02:00
|
|
|
9.3. If this function is run against an older server version, it will
|
|
|
|
fail and return -1.
|
2012-10-07 01:36:48 +02:00
|
|
|
</para>
|
|
|
|
|
2003-03-13 02:30:29 +01:00
|
|
|
</sect2>
|
|
|
|
|
2010-08-09 14:00:24 +02:00
|
|
|
<sect2 id="lo-tell">
|
2003-03-13 02:30:29 +01:00
|
|
|
<title>Obtaining the Seek Position of a Large Object</title>
|
|
|
|
|
|
|
|
<para>
|
2017-10-09 03:44:17 +02:00
|
|
|
<indexterm><primary>lo_tell</primary></indexterm>
|
2004-12-28 23:47:15 +01:00
|
|
|
To obtain the current read or write location of a large object descriptor,
|
2003-03-13 02:30:29 +01:00
|
|
|
call
|
|
|
|
<synopsis>
|
|
|
|
int lo_tell(PGconn *conn, int fd);
|
2012-10-08 01:16:28 +02:00
|
|
|
</synopsis>
|
|
|
|
If there is an error, the return value is -1.
|
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
2017-10-09 03:44:17 +02:00
|
|
|
<indexterm><primary>lo_tell64</primary></indexterm>
|
2012-10-08 01:16:28 +02:00
|
|
|
When dealing with large objects that might exceed 2GB in size,
|
|
|
|
instead use
|
|
|
|
<synopsis>
|
2012-10-07 01:36:48 +02:00
|
|
|
pg_int64 lo_tell64(PGconn *conn, int fd);
|
2003-03-13 02:30:29 +01:00
|
|
|
</synopsis>
|
2012-10-08 01:16:28 +02:00
|
|
|
This function has the same behavior
|
|
|
|
as <function>lo_tell</function>, but it can deliver a result larger
|
|
|
|
than 2GB.
|
|
|
|
Note that <function>lo_tell</function> will fail if the current
|
|
|
|
read/write location is greater than 2GB.
|
2012-10-07 01:36:48 +02:00
|
|
|
</para>
|
2012-10-08 01:16:28 +02:00
|
|
|
|
2012-10-07 01:36:48 +02:00
|
|
|
<para>
|
2017-10-09 03:44:17 +02:00
|
|
|
<function>lo_tell64</function> is new as of <productname>PostgreSQL</productname>
|
2012-10-08 01:16:28 +02:00
|
|
|
9.3. If this function is run against an older server version, it will
|
|
|
|
fail and return -1.
|
1999-06-14 09:36:12 +02:00
|
|
|
</para>
|
|
|
|
</sect2>
|
1998-03-01 09:16:16 +01:00
|
|
|
|
2010-08-09 14:00:24 +02:00
|
|
|
<sect2 id="lo-truncate">
|
2007-03-03 20:52:47 +01:00
|
|
|
<title>Truncating a Large Object</title>
|
|
|
|
|
|
|
|
<para>
|
2017-10-09 03:44:17 +02:00
|
|
|
<indexterm><primary>lo_truncate</primary></indexterm>
|
2007-03-03 20:52:47 +01:00
|
|
|
To truncate a large object to a given length, call
|
|
|
|
<synopsis>
|
2021-09-19 17:36:53 +02:00
|
|
|
int lo_truncate(PGconn *conn, int fd, size_t len);
|
2007-03-03 20:52:47 +01:00
|
|
|
</synopsis>
|
2012-10-08 01:16:28 +02:00
|
|
|
This function truncates the large object
|
2017-10-09 03:44:17 +02:00
|
|
|
descriptor <parameter>fd</parameter> to length <parameter>len</parameter>. The
|
2007-03-03 20:52:47 +01:00
|
|
|
<parameter>fd</parameter> argument must have been returned by a
|
2017-10-09 03:44:17 +02:00
|
|
|
previous <function>lo_open</function>. If <parameter>len</parameter> is
|
2012-10-08 01:16:28 +02:00
|
|
|
greater than the large object's current length, the large object
|
2012-10-09 03:12:27 +02:00
|
|
|
is extended to the specified length with null bytes ('\0').
|
2012-10-08 01:16:28 +02:00
|
|
|
On success, <function>lo_truncate</function> returns
|
|
|
|
zero. On error, the return value is -1.
|
2007-03-03 20:52:47 +01:00
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
2012-10-08 01:16:28 +02:00
|
|
|
The read/write location associated with the descriptor
|
|
|
|
<parameter>fd</parameter> is not changed.
|
2007-03-03 20:52:47 +01:00
|
|
|
</para>
|
|
|
|
|
2012-10-09 03:12:27 +02:00
|
|
|
<para>
|
|
|
|
Although the <parameter>len</parameter> parameter is declared as
|
2017-10-09 03:44:17 +02:00
|
|
|
<type>size_t</type>, <function>lo_truncate</function> will reject length
|
|
|
|
values larger than <literal>INT_MAX</literal>.
|
2012-10-09 03:12:27 +02:00
|
|
|
</para>
|
|
|
|
|
2007-03-03 20:52:47 +01:00
|
|
|
<para>
|
2017-10-09 03:44:17 +02:00
|
|
|
<indexterm><primary>lo_truncate64</primary></indexterm>
|
2012-10-08 01:16:28 +02:00
|
|
|
When dealing with large objects that might exceed 2GB in size,
|
|
|
|
instead use
|
|
|
|
<synopsis>
|
2021-09-19 17:36:53 +02:00
|
|
|
int lo_truncate64(PGconn *conn, int fd, pg_int64 len);
|
2012-10-08 01:16:28 +02:00
|
|
|
</synopsis>
|
|
|
|
This function has the same
|
|
|
|
behavior as <function>lo_truncate</function>, but it can accept a
|
2017-10-09 03:44:17 +02:00
|
|
|
<parameter>len</parameter> value exceeding 2GB.
|
2007-03-03 20:52:47 +01:00
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
2017-10-09 03:44:17 +02:00
|
|
|
<function>lo_truncate</function> is new as of <productname>PostgreSQL</productname>
|
2007-03-03 20:52:47 +01:00
|
|
|
8.3; if this function is run against an older server version, it will
|
2012-10-08 01:16:28 +02:00
|
|
|
fail and return -1.
|
2007-03-03 20:52:47 +01:00
|
|
|
</para>
|
2012-10-08 01:16:28 +02:00
|
|
|
|
2012-10-07 01:36:48 +02:00
|
|
|
<para>
|
2017-10-09 03:44:17 +02:00
|
|
|
<function>lo_truncate64</function> is new as of <productname>PostgreSQL</productname>
|
2012-10-07 01:36:48 +02:00
|
|
|
9.3; if this function is run against an older server version, it will
|
2012-10-08 01:16:28 +02:00
|
|
|
fail and return -1.
|
2012-10-07 01:36:48 +02:00
|
|
|
</para>
|
2007-03-14 01:15:26 +01:00
|
|
|
</sect2>
|
2007-03-03 20:52:47 +01:00
|
|
|
|
2010-08-09 14:00:24 +02:00
|
|
|
<sect2 id="lo-close">
|
1999-06-14 09:36:12 +02:00
|
|
|
<title>Closing a Large Object Descriptor</title>
|
1998-03-01 09:16:16 +01:00
|
|
|
|
1999-06-14 09:36:12 +02:00
|
|
|
<para>
|
2017-10-09 03:44:17 +02:00
|
|
|
<indexterm><primary>lo_close</primary></indexterm>
|
Update documentation on may/can/might:
Standard English uses "may", "can", and "might" in different ways:
may - permission, "You may borrow my rake."
can - ability, "I can lift that log."
might - possibility, "It might rain today."
Unfortunately, in conversational English, their use is often mixed, as
in, "You may use this variable to do X", when in fact, "can" is a better
choice. Similarly, "It may crash" is better stated, "It might crash".
Also update two error messages mentioned in the documenation to match.
2007-01-31 21:56:20 +01:00
|
|
|
A large object descriptor can be closed by calling
|
2003-03-13 02:30:29 +01:00
|
|
|
<synopsis>
|
|
|
|
int lo_close(PGconn *conn, int fd);
|
|
|
|
</synopsis>
|
2017-10-09 03:44:17 +02:00
|
|
|
where <parameter>fd</parameter> is a
|
2003-08-31 19:32:24 +02:00
|
|
|
large object descriptor returned by <function>lo_open</function>.
|
|
|
|
On success, <function>lo_close</function> returns zero. On
|
2012-10-08 01:16:28 +02:00
|
|
|
error, the return value is -1.
|
1999-06-14 09:36:12 +02:00
|
|
|
</para>
|
2003-06-21 23:51:35 +02:00
|
|
|
|
|
|
|
<para>
|
|
|
|
Any large object descriptors that remain open at the end of a
|
|
|
|
transaction will be closed automatically.
|
|
|
|
</para>
|
1998-12-29 03:24:47 +01:00
|
|
|
</sect2>
|
2000-05-15 14:42:23 +02:00
|
|
|
|
2010-08-09 14:00:24 +02:00
|
|
|
<sect2 id="lo-unlink">
|
2000-05-15 14:42:23 +02:00
|
|
|
<title>Removing a Large Object</title>
|
|
|
|
|
|
|
|
<para>
|
2017-10-09 03:44:17 +02:00
|
|
|
<indexterm><primary>lo_unlink</primary></indexterm>
|
2000-05-15 14:42:23 +02:00
|
|
|
To remove a large object from the database, call
|
|
|
|
<synopsis>
|
2003-03-13 02:30:29 +01:00
|
|
|
int lo_unlink(PGconn *conn, Oid lobjId);
|
2000-05-15 14:42:23 +02:00
|
|
|
</synopsis>
|
2012-10-08 01:16:28 +02:00
|
|
|
The <parameter>lobjId</parameter> argument specifies the OID of the
|
2005-01-08 23:13:38 +01:00
|
|
|
large object to remove. Returns 1 if successful, -1 on failure.
|
2000-05-15 14:42:23 +02:00
|
|
|
</para>
|
|
|
|
</sect2>
|
|
|
|
|
1999-06-14 09:36:12 +02:00
|
|
|
</sect1>
|
1998-03-01 09:16:16 +01:00
|
|
|
|
2000-09-29 22:21:34 +02:00
|
|
|
<sect1 id="lo-funcs">
|
2019-09-08 10:26:35 +02:00
|
|
|
<title>Server-Side Functions</title>
|
1998-03-01 09:16:16 +01:00
|
|
|
|
2005-01-08 23:13:38 +01:00
|
|
|
<para>
|
2013-10-28 03:42:46 +01:00
|
|
|
Server-side functions tailored for manipulating large objects from SQL are
|
2017-11-23 15:39:47 +01:00
|
|
|
listed in <xref linkend="lo-funcs-table"/>.
|
2013-10-28 03:42:46 +01:00
|
|
|
</para>
|
|
|
|
|
2020-05-07 20:25:18 +02:00
|
|
|
<table id="lo-funcs-table">
|
|
|
|
<title>SQL-Oriented Large Object Functions</title>
|
|
|
|
<tgroup cols="1">
|
|
|
|
<thead>
|
|
|
|
<row>
|
|
|
|
<entry role="func_table_entry"><para role="func_signature">
|
|
|
|
Function
|
|
|
|
</para>
|
|
|
|
<para>
|
|
|
|
Description
|
|
|
|
</para>
|
|
|
|
<para>
|
|
|
|
Example(s)
|
|
|
|
</para></entry>
|
|
|
|
</row>
|
|
|
|
</thead>
|
|
|
|
|
|
|
|
<tbody>
|
|
|
|
<row>
|
|
|
|
<entry role="func_table_entry"><para role="func_signature">
|
|
|
|
<indexterm>
|
|
|
|
<primary>lo_from_bytea</primary>
|
|
|
|
</indexterm>
|
|
|
|
<function>lo_from_bytea</function> ( <parameter>loid</parameter> <type>oid</type>, <parameter>data</parameter> <type>bytea</type> )
|
|
|
|
<returnvalue>oid</returnvalue>
|
|
|
|
</para>
|
|
|
|
<para>
|
|
|
|
Creates a large object and stores <parameter>data</parameter> in it.
|
|
|
|
If <parameter>loid</parameter> is zero then the system will choose a
|
|
|
|
free OID, otherwise that OID is used (with an error if some large
|
|
|
|
object already has that OID). On success, the large object's OID is
|
|
|
|
returned.
|
|
|
|
</para>
|
|
|
|
<para>
|
|
|
|
<literal>lo_from_bytea(0, '\xffffff00')</literal>
|
|
|
|
<returnvalue>24528</returnvalue>
|
|
|
|
</para></entry>
|
|
|
|
</row>
|
|
|
|
|
|
|
|
<row>
|
|
|
|
<entry role="func_table_entry"><para role="func_signature">
|
|
|
|
<indexterm>
|
|
|
|
<primary>lo_put</primary>
|
|
|
|
</indexterm>
|
|
|
|
<function>lo_put</function> ( <parameter>loid</parameter> <type>oid</type>, <parameter>offset</parameter> <type>bigint</type>, <parameter>data</parameter> <type>bytea</type> )
|
|
|
|
<returnvalue>void</returnvalue>
|
|
|
|
</para>
|
|
|
|
<para>
|
|
|
|
Writes <parameter>data</parameter> starting at the given offset within
|
|
|
|
the large object; the large object is enlarged if necessary.
|
|
|
|
</para>
|
|
|
|
<para>
|
|
|
|
<literal>lo_put(24528, 1, '\xaa')</literal>
|
|
|
|
<returnvalue></returnvalue>
|
|
|
|
</para></entry>
|
|
|
|
</row>
|
|
|
|
|
|
|
|
<row>
|
|
|
|
<entry role="func_table_entry"><para role="func_signature">
|
|
|
|
<indexterm>
|
|
|
|
<primary>lo_get</primary>
|
|
|
|
</indexterm>
|
|
|
|
<function>lo_get</function> ( <parameter>loid</parameter> <type>oid</type> <optional>, <parameter>offset</parameter> <type>bigint</type>, <parameter>length</parameter> <type>integer</type> </optional> )
|
|
|
|
<returnvalue>bytea</returnvalue>
|
|
|
|
</para>
|
|
|
|
<para>
|
|
|
|
Extracts the large object's contents, or a substring thereof.
|
|
|
|
</para>
|
|
|
|
<para>
|
|
|
|
<literal>lo_get(24528, 0, 3)</literal>
|
|
|
|
<returnvalue>\xffaaff</returnvalue>
|
|
|
|
</para></entry>
|
|
|
|
</row>
|
|
|
|
</tbody>
|
|
|
|
</tgroup>
|
|
|
|
</table>
|
2013-10-28 03:42:46 +01:00
|
|
|
|
|
|
|
<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
|
2017-10-09 03:44:17 +02:00
|
|
|
<function>lo_creat</function><indexterm><primary>lo_creat</primary></indexterm>,
|
2013-10-28 15:00:28 +01:00
|
|
|
<function>lo_create</function>,
|
2017-10-09 03:44:17 +02:00
|
|
|
<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>.
|
2005-01-08 23:13:38 +01:00
|
|
|
Here are examples of their use:
|
|
|
|
|
1999-06-14 09:36:12 +02:00
|
|
|
<programlisting>
|
1998-03-01 09:16:16 +01:00
|
|
|
CREATE TABLE image (
|
|
|
|
name text,
|
|
|
|
raster oid
|
|
|
|
);
|
|
|
|
|
2005-01-08 23:13:38 +01:00
|
|
|
SELECT lo_creat(-1); -- returns OID of new, empty large object
|
|
|
|
|
2005-06-13 04:26:53 +02:00
|
|
|
SELECT lo_create(43213); -- attempts to create large object with OID 43213
|
|
|
|
|
2005-01-08 23:13:38 +01:00
|
|
|
SELECT lo_unlink(173454); -- deletes large object with OID 173454
|
|
|
|
|
1998-03-01 09:16:16 +01:00
|
|
|
INSERT INTO image (name, raster)
|
|
|
|
VALUES ('beautiful image', lo_import('/etc/motd'));
|
|
|
|
|
2008-03-22 02:55:14 +01:00
|
|
|
INSERT INTO image (name, raster) -- same as above, but specify OID to use
|
|
|
|
VALUES ('beautiful image', lo_import('/etc/motd', 68583));
|
|
|
|
|
2002-01-07 03:29:15 +01:00
|
|
|
SELECT lo_export(image.raster, '/tmp/motd') FROM image
|
1998-03-01 09:16:16 +01:00
|
|
|
WHERE name = 'beautiful image';
|
1999-06-14 09:36:12 +02:00
|
|
|
</programlisting>
|
2005-01-08 23:13:38 +01:00
|
|
|
</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
|
2017-11-14 18:33:10 +01:00
|
|
|
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.
|
2005-01-08 23:13:38 +01:00
|
|
|
</para>
|
2009-12-11 04:34:57 +01:00
|
|
|
|
2017-11-14 18:33:10 +01:00
|
|
|
<caution>
|
|
|
|
<para>
|
2017-11-23 15:39:47 +01:00
|
|
|
It is possible to <xref linkend="sql-grant"/> use of the
|
2017-11-14 18:33:10 +01:00
|
|
|
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>
|
|
|
|
|
2013-06-12 18:20:59 +02:00
|
|
|
<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
|
2017-10-09 03:44:17 +02:00
|
|
|
these functions as <function>loread</function> and <function>lowrite</function>.
|
2013-06-12 18:20:59 +02:00
|
|
|
</para>
|
|
|
|
|
1999-06-14 09:36:12 +02:00
|
|
|
</sect1>
|
1998-03-01 09:16:16 +01:00
|
|
|
|
2003-03-13 02:30:29 +01:00
|
|
|
<sect1 id="lo-examplesect">
|
|
|
|
<title>Example Program</title>
|
1998-03-01 09:16:16 +01:00
|
|
|
|
1999-06-14 09:36:12 +02:00
|
|
|
<para>
|
2017-11-23 15:39:47 +01:00
|
|
|
<xref linkend="lo-example"/> is a sample program which shows how the large object
|
1998-03-01 09:16:16 +01:00
|
|
|
interface
|
2017-10-09 03:44:17 +02:00
|
|
|
in <application>libpq</application> can be used. Parts of the program are
|
2002-01-07 03:29:15 +01:00
|
|
|
commented out but are left in the source for the reader's
|
2003-03-13 02:30:29 +01:00
|
|
|
benefit. This program can also be found in
|
2002-01-07 03:29:15 +01:00
|
|
|
<filename>src/test/examples/testlo.c</filename> in the source distribution.
|
1999-06-14 09:36:12 +02:00
|
|
|
</para>
|
1998-03-01 09:16:16 +01:00
|
|
|
|
2002-01-07 03:29:15 +01:00
|
|
|
<example id="lo-example">
|
2003-03-13 02:30:29 +01:00
|
|
|
<title>Large Objects with <application>libpq</application> Example Program</title>
|
2008-12-08 00:46:39 +01:00
|
|
|
<programlisting><![CDATA[
|
2020-05-10 22:20:28 +02:00
|
|
|
/*-----------------------------------------------------------------
|
2000-05-02 22:02:03 +02:00
|
|
|
*
|
2013-09-11 03:03:11 +02:00
|
|
|
* testlo.c
|
2000-05-02 22:02:03 +02:00
|
|
|
* test using large objects with libpq
|
|
|
|
*
|
2022-01-08 01:04:57 +01:00
|
|
|
* Portions Copyright (c) 1996-2022, PostgreSQL Global Development Group
|
2013-09-11 03:03:11 +02:00
|
|
|
* Portions Copyright (c) 1994, Regents of the University of California
|
2000-05-02 22:02:03 +02:00
|
|
|
*
|
2013-09-11 03:03:11 +02:00
|
|
|
*
|
|
|
|
* IDENTIFICATION
|
|
|
|
* src/test/examples/testlo.c
|
|
|
|
*
|
2020-05-10 22:20:28 +02:00
|
|
|
*-----------------------------------------------------------------
|
2000-05-02 22:02:03 +02:00
|
|
|
*/
|
2008-12-08 00:46:39 +01:00
|
|
|
#include <stdio.h>
|
2013-09-11 03:03:11 +02:00
|
|
|
#include <stdlib.h>
|
|
|
|
|
|
|
|
#include <sys/types.h>
|
|
|
|
#include <sys/stat.h>
|
|
|
|
#include <fcntl.h>
|
|
|
|
#include <unistd.h>
|
|
|
|
|
2008-12-08 00:46:39 +01:00
|
|
|
#include "libpq-fe.h"
|
|
|
|
#include "libpq/libpq-fs.h"
|
2000-05-02 22:02:03 +02:00
|
|
|
|
2013-09-11 03:03:11 +02:00
|
|
|
#define BUFSIZE 1024
|
2000-05-02 22:02:03 +02:00
|
|
|
|
|
|
|
/*
|
2013-09-11 03:03:11 +02:00
|
|
|
* importFile -
|
2008-12-08 00:46:39 +01:00
|
|
|
* import file "in_filename" into database as large object "lobjOid"
|
2000-05-02 22:02:03 +02:00
|
|
|
*
|
|
|
|
*/
|
2013-09-11 03:03:11 +02:00
|
|
|
static Oid
|
2001-01-20 01:05:54 +01:00
|
|
|
importFile(PGconn *conn, char *filename)
|
2000-05-02 22:02:03 +02:00
|
|
|
{
|
2001-01-20 01:05:54 +01:00
|
|
|
Oid lobjId;
|
|
|
|
int lobj_fd;
|
|
|
|
char buf[BUFSIZE];
|
|
|
|
int nbytes,
|
|
|
|
tmp;
|
|
|
|
int fd;
|
2000-05-02 22:02:03 +02:00
|
|
|
|
|
|
|
/*
|
|
|
|
* open the file to be read in
|
|
|
|
*/
|
|
|
|
fd = open(filename, O_RDONLY, 0666);
|
2008-12-08 00:46:39 +01:00
|
|
|
if (fd < 0)
|
2001-01-20 01:05:54 +01:00
|
|
|
{ /* error */
|
2013-09-11 03:03:11 +02:00
|
|
|
fprintf(stderr, "cannot open unix file\"%s\"\n", filename);
|
2000-05-02 22:02:03 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* create the large object
|
|
|
|
*/
|
2001-01-20 01:05:54 +01:00
|
|
|
lobjId = lo_creat(conn, INV_READ | INV_WRITE);
|
|
|
|
if (lobjId == 0)
|
2013-09-11 03:03:11 +02:00
|
|
|
fprintf(stderr, "cannot create large object");
|
2000-05-02 22:02:03 +02:00
|
|
|
|
|
|
|
lobj_fd = lo_open(conn, lobjId, INV_WRITE);
|
2001-01-20 01:05:54 +01:00
|
|
|
|
2000-05-02 22:02:03 +02:00
|
|
|
/*
|
|
|
|
* read in from the Unix file and write to the inversion file
|
|
|
|
*/
|
2008-12-08 00:46:39 +01:00
|
|
|
while ((nbytes = read(fd, buf, BUFSIZE)) > 0)
|
2001-01-20 01:05:54 +01:00
|
|
|
{
|
|
|
|
tmp = lo_write(conn, lobj_fd, buf, nbytes);
|
2008-12-08 00:46:39 +01:00
|
|
|
if (tmp < nbytes)
|
2013-09-11 03:03:11 +02:00
|
|
|
fprintf(stderr, "error while reading \"%s\"", filename);
|
2000-05-02 22:02:03 +02:00
|
|
|
}
|
|
|
|
|
2013-09-11 03:03:11 +02:00
|
|
|
close(fd);
|
|
|
|
lo_close(conn, lobj_fd);
|
2000-05-02 22:02:03 +02:00
|
|
|
|
|
|
|
return lobjId;
|
|
|
|
}
|
|
|
|
|
2013-09-11 03:03:11 +02:00
|
|
|
static void
|
2001-01-20 01:05:54 +01:00
|
|
|
pickout(PGconn *conn, Oid lobjId, int start, int len)
|
2000-05-02 22:02:03 +02:00
|
|
|
{
|
2001-01-20 01:05:54 +01:00
|
|
|
int lobj_fd;
|
|
|
|
char *buf;
|
|
|
|
int nbytes;
|
|
|
|
int nread;
|
2000-05-02 22:02:03 +02:00
|
|
|
|
|
|
|
lobj_fd = lo_open(conn, lobjId, INV_READ);
|
2008-12-08 00:46:39 +01:00
|
|
|
if (lobj_fd < 0)
|
2013-09-11 03:03:11 +02:00
|
|
|
fprintf(stderr, "cannot open large object %u", lobjId);
|
2000-05-02 22:02:03 +02:00
|
|
|
|
|
|
|
lo_lseek(conn, lobj_fd, start, SEEK_SET);
|
2001-01-20 01:05:54 +01:00
|
|
|
buf = malloc(len + 1);
|
2000-05-02 22:02:03 +02:00
|
|
|
|
|
|
|
nread = 0;
|
2008-12-08 00:46:39 +01:00
|
|
|
while (len - nread > 0)
|
2001-01-20 01:05:54 +01:00
|
|
|
{
|
|
|
|
nbytes = lo_read(conn, lobj_fd, buf, len - nread);
|
2013-09-11 03:03:11 +02:00
|
|
|
buf[nbytes] = '\0';
|
2008-12-08 00:46:39 +01:00
|
|
|
fprintf(stderr, ">>> %s", buf);
|
2001-01-20 01:05:54 +01:00
|
|
|
nread += nbytes;
|
2013-09-11 03:03:11 +02:00
|
|
|
if (nbytes <= 0)
|
|
|
|
break; /* no more data? */
|
2000-05-02 22:02:03 +02:00
|
|
|
}
|
2001-01-20 01:05:54 +01:00
|
|
|
free(buf);
|
2008-12-08 00:46:39 +01:00
|
|
|
fprintf(stderr, "\n");
|
2000-05-02 22:02:03 +02:00
|
|
|
lo_close(conn, lobj_fd);
|
|
|
|
}
|
|
|
|
|
2013-09-11 03:03:11 +02:00
|
|
|
static void
|
2001-01-20 01:05:54 +01:00
|
|
|
overwrite(PGconn *conn, Oid lobjId, int start, int len)
|
2000-05-02 22:02:03 +02:00
|
|
|
{
|
2001-01-20 01:05:54 +01:00
|
|
|
int lobj_fd;
|
|
|
|
char *buf;
|
|
|
|
int nbytes;
|
|
|
|
int nwritten;
|
|
|
|
int i;
|
2000-05-02 22:02:03 +02:00
|
|
|
|
2006-03-02 22:49:09 +01:00
|
|
|
lobj_fd = lo_open(conn, lobjId, INV_WRITE);
|
2008-12-08 00:46:39 +01:00
|
|
|
if (lobj_fd < 0)
|
2013-09-11 03:03:11 +02:00
|
|
|
fprintf(stderr, "cannot open large object %u", lobjId);
|
2000-05-02 22:02:03 +02:00
|
|
|
|
|
|
|
lo_lseek(conn, lobj_fd, start, SEEK_SET);
|
2001-01-20 01:05:54 +01:00
|
|
|
buf = malloc(len + 1);
|
2000-05-02 22:02:03 +02:00
|
|
|
|
2008-12-08 00:46:39 +01:00
|
|
|
for (i = 0; i < len; i++)
|
2001-01-20 01:05:54 +01:00
|
|
|
buf[i] = 'X';
|
2013-09-11 03:03:11 +02:00
|
|
|
buf[i] = '\0';
|
2000-05-02 22:02:03 +02:00
|
|
|
|
|
|
|
nwritten = 0;
|
2008-12-08 00:46:39 +01:00
|
|
|
while (len - nwritten > 0)
|
2001-01-20 01:05:54 +01:00
|
|
|
{
|
|
|
|
nbytes = lo_write(conn, lobj_fd, buf + nwritten, len - nwritten);
|
|
|
|
nwritten += nbytes;
|
2013-09-11 03:03:11 +02:00
|
|
|
if (nbytes <= 0)
|
|
|
|
{
|
|
|
|
fprintf(stderr, "\nWRITE FAILED!\n");
|
|
|
|
break;
|
|
|
|
}
|
2000-05-02 22:02:03 +02:00
|
|
|
}
|
2001-01-20 01:05:54 +01:00
|
|
|
free(buf);
|
2008-12-08 00:46:39 +01:00
|
|
|
fprintf(stderr, "\n");
|
2000-05-02 22:02:03 +02:00
|
|
|
lo_close(conn, lobj_fd);
|
|
|
|
}
|
|
|
|
|
2013-09-11 03:03:11 +02:00
|
|
|
|
2000-05-02 22:02:03 +02:00
|
|
|
/*
|
2013-09-11 03:03:11 +02:00
|
|
|
* exportFile -
|
2008-12-08 00:46:39 +01:00
|
|
|
* export large object "lobjOid" to file "out_filename"
|
2000-05-02 22:02:03 +02:00
|
|
|
*
|
|
|
|
*/
|
2013-09-11 03:03:11 +02:00
|
|
|
static void
|
2001-01-20 01:05:54 +01:00
|
|
|
exportFile(PGconn *conn, Oid lobjId, char *filename)
|
2000-05-02 22:02:03 +02:00
|
|
|
{
|
2001-01-20 01:05:54 +01:00
|
|
|
int lobj_fd;
|
|
|
|
char buf[BUFSIZE];
|
|
|
|
int nbytes,
|
|
|
|
tmp;
|
|
|
|
int fd;
|
2000-05-02 22:02:03 +02:00
|
|
|
|
|
|
|
/*
|
2006-03-02 22:49:09 +01:00
|
|
|
* open the large object
|
2000-05-02 22:02:03 +02:00
|
|
|
*/
|
|
|
|
lobj_fd = lo_open(conn, lobjId, INV_READ);
|
2008-12-08 00:46:39 +01:00
|
|
|
if (lobj_fd < 0)
|
2013-09-11 03:03:11 +02:00
|
|
|
fprintf(stderr, "cannot open large object %u", lobjId);
|
2000-05-02 22:02:03 +02:00
|
|
|
|
|
|
|
/*
|
|
|
|
* open the file to be written to
|
|
|
|
*/
|
2013-09-11 03:03:11 +02:00
|
|
|
fd = open(filename, O_CREAT | O_WRONLY | O_TRUNC, 0666);
|
2008-12-08 00:46:39 +01:00
|
|
|
if (fd < 0)
|
2001-01-20 01:05:54 +01:00
|
|
|
{ /* error */
|
2013-09-11 03:03:11 +02:00
|
|
|
fprintf(stderr, "cannot open unix file\"%s\"",
|
2001-01-20 01:05:54 +01:00
|
|
|
filename);
|
2000-05-02 22:02:03 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
2006-03-02 22:49:09 +01:00
|
|
|
* read in from the inversion file and write to the Unix file
|
2000-05-02 22:02:03 +02:00
|
|
|
*/
|
2008-12-08 00:46:39 +01:00
|
|
|
while ((nbytes = lo_read(conn, lobj_fd, buf, BUFSIZE)) > 0)
|
2001-01-20 01:05:54 +01:00
|
|
|
{
|
|
|
|
tmp = write(fd, buf, nbytes);
|
2008-12-08 00:46:39 +01:00
|
|
|
if (tmp < nbytes)
|
2001-01-20 01:05:54 +01:00
|
|
|
{
|
2013-09-11 03:03:11 +02:00
|
|
|
fprintf(stderr, "error while writing \"%s\"",
|
2001-01-20 01:05:54 +01:00
|
|
|
filename);
|
|
|
|
}
|
2000-05-02 22:02:03 +02:00
|
|
|
}
|
|
|
|
|
2013-09-11 03:03:11 +02:00
|
|
|
lo_close(conn, lobj_fd);
|
|
|
|
close(fd);
|
2000-05-02 22:02:03 +02:00
|
|
|
}
|
|
|
|
|
2013-09-11 03:03:11 +02:00
|
|
|
static void
|
2001-01-20 01:05:54 +01:00
|
|
|
exit_nicely(PGconn *conn)
|
2000-05-02 22:02:03 +02:00
|
|
|
{
|
2001-01-20 01:05:54 +01:00
|
|
|
PQfinish(conn);
|
|
|
|
exit(1);
|
2000-05-02 22:02:03 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
int
|
|
|
|
main(int argc, char **argv)
|
|
|
|
{
|
2001-01-20 01:05:54 +01:00
|
|
|
char *in_filename,
|
|
|
|
*out_filename;
|
|
|
|
char *database;
|
|
|
|
Oid lobjOid;
|
|
|
|
PGconn *conn;
|
|
|
|
PGresult *res;
|
|
|
|
|
|
|
|
if (argc != 4)
|
|
|
|
{
|
2008-12-08 00:46:39 +01:00
|
|
|
fprintf(stderr, "Usage: %s database_name in_filename out_filename\n",
|
2001-01-20 01:05:54 +01:00
|
|
|
argv[0]);
|
|
|
|
exit(1);
|
2000-05-02 22:02:03 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
database = argv[1];
|
|
|
|
in_filename = argv[2];
|
|
|
|
out_filename = argv[3];
|
|
|
|
|
|
|
|
/*
|
|
|
|
* set up the connection
|
|
|
|
*/
|
|
|
|
conn = PQsetdb(NULL, NULL, NULL, NULL, database);
|
|
|
|
|
|
|
|
/* check to see that the backend connection was successfully made */
|
2013-09-11 03:03:11 +02:00
|
|
|
if (PQstatus(conn) != CONNECTION_OK)
|
2001-01-20 01:05:54 +01:00
|
|
|
{
|
2021-01-22 22:52:31 +01:00
|
|
|
fprintf(stderr, "%s", PQerrorMessage(conn));
|
2001-01-20 01:05:54 +01:00
|
|
|
exit_nicely(conn);
|
2000-05-02 22:02:03 +02:00
|
|
|
}
|
|
|
|
|
2018-11-02 13:55:57 +01:00
|
|
|
/* Set always-secure search path, so malicious users can't take control. */
|
Document security implications of search_path and the public schema.
The ability to create like-named objects in different schemas opens up
the potential for users to change the behavior of other users' queries,
maliciously or accidentally. When you connect to a PostgreSQL server,
you should remove from your search_path any schema for which a user
other than yourself or superusers holds the CREATE privilege. If you do
not, other users holding CREATE privilege can redefine the behavior of
your commands, causing them to perform arbitrary SQL statements under
your identity. "SET search_path = ..." and "SELECT
pg_catalog.set_config(...)" are not vulnerable to such hijacking, so one
can use either as the first command of a session. As special
exceptions, the following client applications behave as documented
regardless of search_path settings and schema privileges: clusterdb
createdb createlang createuser dropdb droplang dropuser ecpg (not
programs it generates) initdb oid2name pg_archivecleanup pg_basebackup
pg_config pg_controldata pg_ctl pg_dump pg_dumpall pg_isready
pg_receivewal pg_recvlogical pg_resetwal pg_restore pg_rewind pg_standby
pg_test_fsync pg_test_timing pg_upgrade pg_waldump reindexdb vacuumdb
vacuumlo. Not included are core client programs that run user-specified
SQL commands, namely psql and pgbench. PostgreSQL encourages non-core
client applications to do likewise.
Document this in the context of libpq connections, psql connections,
dblink connections, ECPG connections, extension packaging, and schema
usage patterns. The principal defense for applications is "SELECT
pg_catalog.set_config('search_path', '', false)", and the principal
defense for databases is "REVOKE CREATE ON SCHEMA public FROM PUBLIC".
Either one is sufficient to prevent attack. After a REVOKE, consider
auditing the public schema for objects named like pg_catalog objects.
Authors of SECURITY DEFINER functions use some of the same defenses, and
the CREATE FUNCTION reference page already covered them thoroughly.
This is a good opportunity to audit SECURITY DEFINER functions for
robust security practice.
Back-patch to 9.3 (all supported versions).
Reviewed by Michael Paquier and Jonathan S. Katz. Reported by Arseniy
Sharoglazov.
Security: CVE-2018-1058
2018-02-26 16:39:44 +01:00
|
|
|
res = PQexec(conn,
|
|
|
|
"SELECT pg_catalog.set_config('search_path', '', false)");
|
2018-07-01 14:06:40 +02:00
|
|
|
if (PQresultStatus(res) != PGRES_TUPLES_OK)
|
Document security implications of search_path and the public schema.
The ability to create like-named objects in different schemas opens up
the potential for users to change the behavior of other users' queries,
maliciously or accidentally. When you connect to a PostgreSQL server,
you should remove from your search_path any schema for which a user
other than yourself or superusers holds the CREATE privilege. If you do
not, other users holding CREATE privilege can redefine the behavior of
your commands, causing them to perform arbitrary SQL statements under
your identity. "SET search_path = ..." and "SELECT
pg_catalog.set_config(...)" are not vulnerable to such hijacking, so one
can use either as the first command of a session. As special
exceptions, the following client applications behave as documented
regardless of search_path settings and schema privileges: clusterdb
createdb createlang createuser dropdb droplang dropuser ecpg (not
programs it generates) initdb oid2name pg_archivecleanup pg_basebackup
pg_config pg_controldata pg_ctl pg_dump pg_dumpall pg_isready
pg_receivewal pg_recvlogical pg_resetwal pg_restore pg_rewind pg_standby
pg_test_fsync pg_test_timing pg_upgrade pg_waldump reindexdb vacuumdb
vacuumlo. Not included are core client programs that run user-specified
SQL commands, namely psql and pgbench. PostgreSQL encourages non-core
client applications to do likewise.
Document this in the context of libpq connections, psql connections,
dblink connections, ECPG connections, extension packaging, and schema
usage patterns. The principal defense for applications is "SELECT
pg_catalog.set_config('search_path', '', false)", and the principal
defense for databases is "REVOKE CREATE ON SCHEMA public FROM PUBLIC".
Either one is sufficient to prevent attack. After a REVOKE, consider
auditing the public schema for objects named like pg_catalog objects.
Authors of SECURITY DEFINER functions use some of the same defenses, and
the CREATE FUNCTION reference page already covered them thoroughly.
This is a good opportunity to audit SECURITY DEFINER functions for
robust security practice.
Back-patch to 9.3 (all supported versions).
Reviewed by Michael Paquier and Jonathan S. Katz. Reported by Arseniy
Sharoglazov.
Security: CVE-2018-1058
2018-02-26 16:39:44 +01:00
|
|
|
{
|
|
|
|
fprintf(stderr, "SET failed: %s", PQerrorMessage(conn));
|
|
|
|
PQclear(res);
|
|
|
|
exit_nicely(conn);
|
|
|
|
}
|
|
|
|
PQclear(res);
|
|
|
|
|
2008-12-08 00:46:39 +01:00
|
|
|
res = PQexec(conn, "begin");
|
2000-05-02 22:02:03 +02:00
|
|
|
PQclear(res);
|
2013-09-11 03:03:11 +02:00
|
|
|
printf("importing file \"%s\" ...\n", in_filename);
|
2000-05-02 22:02:03 +02:00
|
|
|
/* lobjOid = importFile(conn, in_filename); */
|
|
|
|
lobjOid = lo_import(conn, in_filename);
|
2013-09-11 03:03:11 +02:00
|
|
|
if (lobjOid == 0)
|
|
|
|
fprintf(stderr, "%s\n", PQerrorMessage(conn));
|
|
|
|
else
|
|
|
|
{
|
|
|
|
printf("\tas large object %u.\n", lobjOid);
|
2000-05-02 22:02:03 +02:00
|
|
|
|
2013-09-11 03:03:11 +02:00
|
|
|
printf("picking out bytes 1000-2000 of the large object\n");
|
|
|
|
pickout(conn, lobjOid, 1000, 1000);
|
2000-05-02 22:02:03 +02:00
|
|
|
|
2013-09-11 03:03:11 +02:00
|
|
|
printf("overwriting bytes 1000-2000 of the large object with X's\n");
|
|
|
|
overwrite(conn, lobjOid, 1000, 1000);
|
2000-05-02 22:02:03 +02:00
|
|
|
|
2013-09-11 03:03:11 +02:00
|
|
|
printf("exporting large object to file \"%s\" ...\n", out_filename);
|
|
|
|
/* exportFile(conn, lobjOid, out_filename); */
|
|
|
|
if (lo_export(conn, lobjOid, out_filename) < 0)
|
|
|
|
fprintf(stderr, "%s\n", PQerrorMessage(conn));
|
|
|
|
}
|
2000-05-02 22:02:03 +02:00
|
|
|
|
2008-12-08 00:46:39 +01:00
|
|
|
res = PQexec(conn, "end");
|
2000-05-02 22:02:03 +02:00
|
|
|
PQclear(res);
|
|
|
|
PQfinish(conn);
|
2013-09-11 03:03:11 +02:00
|
|
|
return 0;
|
2000-05-02 22:02:03 +02:00
|
|
|
}
|
2008-12-08 00:46:39 +01:00
|
|
|
]]>
|
1999-06-14 09:36:12 +02:00
|
|
|
</programlisting>
|
2001-09-15 18:08:59 +02:00
|
|
|
</example>
|
1999-06-14 09:36:12 +02:00
|
|
|
|
|
|
|
</sect1>
|
|
|
|
</chapter>
|