X-Git-Url: https://granicus.if.org/sourcecode?a=blobdiff_plain;f=doc%2Fsrc%2Fsgml%2Flobj.sgml;h=7757e1e4413da0c0c5e59f347ed1f2a7cec8f474;hb=1d25779284fe1ba08ecd57e647292a9deb241376;hp=4cdac668f0d01b95fef5a944456a048ad76836ad;hpb=8442a92e5a193dd63593ee336158d8ec92e81fff;p=postgresql diff --git a/doc/src/sgml/lobj.sgml b/doc/src/sgml/lobj.sgml index 4cdac668f0..7757e1e441 100644 --- a/doc/src/sgml/lobj.sgml +++ b/doc/src/sgml/lobj.sgml @@ -1,23 +1,17 @@ - + - Large Objects + Large Objects large object BLOBlarge object - In PostgreSQL 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, PostgreSQL - 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. + PostgreSQL has a large object + 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. @@ -26,43 +20,40 @@ $Header: /cvsroot/pgsql/doc/src/sgml/lobj.sgml,v 1.31 2003/11/01 01:56:29 petere large object data. We use the libpq C library for the examples in this chapter, but most programming interfaces native to PostgreSQL support - equivalent functionality. Other interfaces may use the large + equivalent functionality. Other interfaces might use the large object interface internally to provide generic support for large values. This is not described here. - - History + + Introduction + + + TOAST + versus large objects + - POSTGRES 4.2, the indirect predecessor - of PostgreSQL, supported three standard - implementations of large objects: as files external to the - POSTGRES server, as external files - managed by the POSTGRES server, and as - data stored within the POSTGRES - database. This caused considerable confusion among users. As a - result, only support for large objects as data stored within the - database is retained in PostgreSQL. - Even though this is slower to access, it provides stricter data - integrity. For historical reasons, this storage scheme is - referred to as Inversion large - objects. (You will see the term Inversion used - occasionally to mean the same thing as large object.) Since - PostgreSQL 7.1, all large objects are - placed in one system table called - pg_largeobject. + All large objects are stored in a single system table named pg_largeobject. + Each large object also has an entry in the system table pg_largeobject_metadata. + Large objects can be created, modified, and deleted using a read/write API + that is similar to standard operations on files. - TOAST - sliced breadTOAST - PostgreSQL 7.1 introduced a mechanism - (nicknamed TOAST) 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 TOAST can only handle 1 GB. + PostgreSQL also supports a storage system called + TOAST, + which automatically stores values + larger than a single database page into a secondary storage area per table. + This makes the large object facility partially obsolete. One + remaining advantage of the large object facility is that it allows values + up to 4 TB in size, whereas TOASTed fields can be at + most 1 GB. Also, reading and updating portions of a large object can be + done efficiently, while most operations on a TOASTed + field will read or write the whole value as a unit. @@ -71,12 +62,38 @@ $Header: /cvsroot/pgsql/doc/src/sgml/lobj.sgml,v 1.31 2003/11/01 01:56:29 petere Implementation Features - The large object implementation breaks large - objects up into chunks and stores the chunks in + 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 + and + . + 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 + run-time parameter. + @@ -84,194 +101,403 @@ $Header: /cvsroot/pgsql/doc/src/sgml/lobj.sgml,v 1.31 2003/11/01 01:56:29 petere This section describes the facilities that - PostgreSQL client interface libraries - provide for accessing large objects. All large object - manipulation using these functions must take - place within an SQL transaction block. (This requirement is - strictly enforced as of PostgreSQL 6.5, though it - has been an implicit requirement in previous versions, resulting - in misbehavior if ignored.) - The PostgreSQL large object interface is modeled after - the Unix file-system interface, with analogues of - open, read, + PostgreSQL's libpq + client interface library provides for accessing large objects. + The PostgreSQL large object interface is + modeled after the Unix file-system interface, with + analogues of open, read, write, lseek, etc. - Client applications which use the large object interface in - libpq should include the header file + All large object manipulation using these functions + must take place within an SQL transaction block, + since large object file descriptors are only valid for the duration of + a transaction. + + + + 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 + can be retrieved with PQerrorMessage. + + + + Client applications that use these functions should include the header file libpq/libpq-fs.h and link with the libpq library. - + Creating a Large Object + lo_creat The function Oid lo_creat(PGconn *conn, int mode); - lo_creat - creates a new large object. - mode is a bit mask - describing several different attributes of the new - object. The symbolic constants listed here are defined - in the header file libpq/libpq-fs.h. - The access type (read, write, or both) is controlled by - or'ing together the bits INV_READ and - INV_WRITE. 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. + creates a new large object. + The return value is the OID that was assigned to the new large object, + or InvalidOid (zero) on failure. + + mode is unused and + ignored as of PostgreSQL 8.1; however, for + backward compatibility with earlier releases it is best to + set it to INV_READ, INV_WRITE, + or INV_READ | INV_WRITE. + (These symbolic constants are defined + in the header file libpq/libpq-fs.h.) + + + + An example: + +inv_oid = lo_creat(conn, INV_READ|INV_WRITE); + + + + + lo_create + The function + +Oid lo_create(PGconn *conn, Oid lobjId); + + also creates a new large object. The OID to be assigned can be + specified by lobjId; + if so, failure occurs if that OID is already in use for some large + object. If lobjId + is InvalidOid (zero) then lo_create assigns an unused + OID (this is the same behavior as lo_creat). + The return value is the OID that was assigned to the new large object, + or InvalidOid (zero) on failure. + + + + lo_create is new as of PostgreSQL + 8.1; if this function is run against an older server version, it will + fail and return InvalidOid. An example: -inv_oid = lo_creat(INV_READ|INV_WRITE); +inv_oid = lo_create(conn, desired_oid); - + Importing a Large Object + lo_import To import an operating system file as a large object, call Oid lo_import(PGconn *conn, const char *filename); - lo_import - filename + filename 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. + The return value is the OID that was assigned to the new large object, + or InvalidOid (zero) on failure. + Note that the file is read by the client interface library, not by + the server; so it must exist in the client file system and be readable + by the client application. + + + + lo_import_with_oid + The function + +Oid lo_import_with_oid(PGconn *conn, const char *filename, Oid lobjId); + + also imports a new large object. The OID to be assigned can be + specified by lobjId; + if so, failure occurs if that OID is already in use for some large + object. If lobjId + is InvalidOid (zero) then lo_import_with_oid assigns an unused + OID (this is the same behavior as lo_import). + The return value is the OID that was assigned to the new large object, + or InvalidOid (zero) on failure. + + + + lo_import_with_oid is new as of PostgreSQL + 8.4 and uses lo_create internally which is new in 8.1; if this function is run against 8.0 or before, it will + fail and return InvalidOid. - + Exporting a Large Object + lo_export To export a large object into an operating system file, call int lo_export(PGconn *conn, Oid lobjId, const char *filename); - lo_export - The lobjId argument specifies the OID of the large - object to export and the filename argument specifies - the operating system name name of the file. + The lobjId argument specifies the OID of the large + object to export and the filename 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. - + Opening an Existing Large Object - To open an existing large object, call + lo_open + To open an existing large object for reading or writing, call int lo_open(PGconn *conn, Oid lobjId, int mode); - lo_open - 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 (INV_WRITE), 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. The descriptor is only valid for + 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 + (INV_WRITE), or both. + (These symbolic constants are defined + in the header file libpq/libpq-fs.h.) + lo_open returns a (non-negative) large object + descriptor for later use in lo_read, + lo_write, lo_lseek, + lo_lseek64, lo_tell, + lo_tell64, lo_truncate, + lo_truncate64, and lo_close. + The descriptor is only valid for the duration of the current transaction. - + On failure, -1 is returned. + + + + The server currently does not distinguish between modes + INV_WRITE and INV_READ | + INV_WRITE: you are allowed to read from the descriptor + in either case. However there is a significant difference between + these modes and INV_READ alone: with INV_READ + 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 + snapshot that was active when lo_open was executed, + regardless of later writes by this or other transactions. Reading + from a descriptor opened with INV_WRITE returns + data that reflects all writes of other committed transactions as well + as writes of the current transaction. This is similar to the behavior + of REPEATABLE READ versus READ COMMITTED transaction + modes for ordinary SQL SELECT commands. + + + + An example: + +inv_fd = lo_open(conn, inv_oid, INV_READ|INV_WRITE); + + - + Writing Data to a Large Object + lo_write The function int lo_write(PGconn *conn, int fd, const char *buf, size_t len); - lo_write 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. + writes len bytes from buf + (which must be of size len) to large object + descriptor fd. The fd argument must + have been returned by a previous lo_open. The + number of bytes actually written is returned (in the current + implementation, this will always equal len unless + there is an error). In the event of an error, the return value is -1. + + + + Although the len parameter is declared as + size_t, this function will reject length values larger than + INT_MAX. In practice, it's best to transfer data in chunks + of at most a few megabytes anyway. - + Reading Data from a Large Object + lo_read The function int lo_read(PGconn *conn, int fd, char *buf, size_t len); - lo_read reads - len bytes from large object - fd into buf. The - fd argument must have been returned by a - previous lo_open. The number of bytes - actually read is returned. In the event of an error, the return - value is negative. + reads up to len bytes from large object descriptor + fd into buf (which must be + of size len). The fd + argument must have been returned by a previous + lo_open. The number of bytes actually read is + returned; this will be less than len if the end of + the large object is reached first. In the event of an error, the return + value is -1. + + + + Although the len parameter is declared as + size_t, this function will reject length values larger than + INT_MAX. In practice, it's best to transfer data in chunks + of at most a few megabytes anyway. - -Seeking on a Large Object + +Seeking in a Large Object - To change the current read or write location on a large - object, call + lo_lseek + To change the current read or write location associated with a + large object descriptor, call int lo_lseek(PGconn *conn, int fd, int offset, int whence); - lo_lseek This function moves the - current location pointer for the large object described by + This function moves the + current location pointer for the large object descriptor identified by fd to the new location specified by offset. The valid values for whence are SEEK_SET (seek from object start), SEEK_CUR (seek from current position), and SEEK_END (seek from object end). The return value is - the new location pointer. + the new location pointer, or -1 on error. + + + + lo_lseek64 + When dealing with large objects that might exceed 2GB in size, + instead use + +pg_int64 lo_lseek64(PGconn *conn, int fd, pg_int64 offset, int whence); + + This function has the same behavior + as lo_lseek, but it can accept an + offset larger than 2GB and/or deliver a result larger + than 2GB. + Note that lo_lseek will fail if the new location + pointer would be greater than 2GB. + + + lo_lseek64 is new as of PostgreSQL + 9.3. If this function is run against an older server version, it will + fail and return -1. + + - + Obtaining the Seek Position of a Large Object - To obtain the current read or write location of a large object, + lo_tell + To obtain the current read or write location of a large object descriptor, call int lo_tell(PGconn *conn, int fd); - lo_tell If there is an error, the - return value is negative. + If there is an error, the return value is -1. + + + + lo_tell64 + When dealing with large objects that might exceed 2GB in size, + instead use + +pg_int64 lo_tell64(PGconn *conn, int fd); + + This function has the same behavior + as lo_tell, but it can deliver a result larger + than 2GB. + Note that lo_tell will fail if the current + read/write location is greater than 2GB. + + + + lo_tell64 is new as of PostgreSQL + 9.3. If this function is run against an older server version, it will + fail and return -1. + + + + +Truncating a Large Object + + + lo_truncate + To truncate a large object to a given length, call + +int lo_truncate(PGcon *conn, int fd, size_t len); + + This function truncates the large object + descriptor fd to length len. The + fd argument must have been returned by a + previous lo_open. If len is + greater than the large object's current length, the large object + is extended to the specified length with null bytes ('\0'). + On success, lo_truncate returns + zero. On error, the return value is -1. + + + + The read/write location associated with the descriptor + fd is not changed. + + + + Although the len parameter is declared as + size_t, lo_truncate will reject length + values larger than INT_MAX. + + + + lo_truncate64 + When dealing with large objects that might exceed 2GB in size, + instead use + +int lo_truncate64(PGcon *conn, int fd, pg_int64 len); + + This function has the same + behavior as lo_truncate, but it can accept a + len value exceeding 2GB. + + + + lo_truncate is new as of PostgreSQL + 8.3; if this function is run against an older server version, it will + fail and return -1. + + + + lo_truncate64 is new as of PostgreSQL + 9.3; if this function is run against an older server version, it will + fail and return -1. - + Closing a Large Object Descriptor - A large object may be closed by calling + lo_close + A large object descriptor can be closed by calling int lo_close(PGconn *conn, int fd); - lo_close where fd is a + where fd is a large object descriptor returned by lo_open. On success, lo_close returns zero. On - error, the return value is negative. + error, the return value is -1. @@ -280,65 +506,157 @@ int lo_close(PGconn *conn, int fd); - + Removing a Large Object + lo_unlink To remove a large object from the database, call int lo_unlink(PGconn *conn, Oid lobjId); - lo_unlink The - lobjId argument specifies the OID of the - large object to remove. In the event of an error, the return - value is negative. + The lobjId argument specifies the OID of the + large object to remove. Returns 1 if successful, -1 on failure. - Server-side Functions - - There are two built-in server-side functions, - lo_importlo_import - and - lo_export,lo_export - for large object access, which are available for use in - SQL commands. Here is an example of their - use: + + Server-side functions tailored for manipulating large objects from SQL are + listed in . + + + + SQL-oriented Large Object Functions + + + + Function + Return Type + Description + Example + Result + + + + + + + + lo_from_bytea + + lo_from_bytea(loid oid, string bytea) + + oid + + Create a large object and store data there, returning its OID. + Pass 0 to have the system choose an OID. + + lo_from_bytea(0, E'\\xffffff00') + 24528 + + + + + + lo_put + + lo_put(loid oid, offset bigint, str bytea) + + void + + Write data at the given offset. + + lo_put(24528, 1, E'\\xaa') + + + + + + + lo_get + + lo_get(loid oid , from bigint, for int) + + bytea + + Extract contents or a substring thereof. + + lo_get(24528, 0, 3) + \xffaaff + + + + +
+ + + 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 + lo_creatlo_creat, + lo_create, + lo_unlinklo_unlink, + lo_importlo_import, and + lo_exportlo_export. + Here are examples of their use: + 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'; - + + + + The server-side lo_import and + lo_export 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, 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 superuser privilege. + + + + The functionality of lo_read and + lo_write 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 loread and lowrite. + - -These functions read and write files in the server's file system, using the -permissions of the database's owning user. Therefore, 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. Their use is not restricted.) - Example Program - is a sample program which shows how the large object + is a sample program which shows how the large object interface - in libpq can be used. Parts of the program are + in libpq 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 src/test/examples/testlo.c in the source distribution. @@ -346,28 +664,40 @@ the client program. Their use is not restricted.) Large Objects with <application>libpq</application> Example Program - -/*-------------------------------------------------------------- + +#include -#define BUFSIZE 1024 +#include +#include +#include +#include + +#include "libpq-fe.h" +#include "libpq/libpq-fs.h" + +#define BUFSIZE 1024 /* - * importFile - * import file "in_filename" into database as large object "lobjOid" + * importFile - + * import file "in_filename" into database as large object "lobjOid" * */ -Oid +static Oid importFile(PGconn *conn, char *filename) { Oid lobjId; @@ -381,9 +711,9 @@ importFile(PGconn *conn, char *filename) * open the file to be read in */ fd = open(filename, O_RDONLY, 0666); - if (fd < 0) + if (fd < 0) { /* error */ - fprintf(stderr, "can't open unix file %s\n", filename); + fprintf(stderr, "cannot open unix file\"%s\"\n", filename); } /* @@ -391,27 +721,27 @@ importFile(PGconn *conn, char *filename) */ lobjId = lo_creat(conn, INV_READ | INV_WRITE); if (lobjId == 0) - fprintf(stderr, "can't create large object\n"); + fprintf(stderr, "cannot create large object"); lobj_fd = lo_open(conn, lobjId, INV_WRITE); /* * read in from the Unix file and write to the inversion file */ - while ((nbytes = read(fd, buf, BUFSIZE)) > 0) + while ((nbytes = read(fd, buf, BUFSIZE)) > 0) { tmp = lo_write(conn, lobj_fd, buf, nbytes); - if (tmp < nbytes) - fprintf(stderr, "error while reading large object\n"); + if (tmp < nbytes) + fprintf(stderr, "error while reading \"%s\"", filename); } - (void) close(fd); - (void) lo_close(conn, lobj_fd); + close(fd); + lo_close(conn, lobj_fd); return lobjId; } -void +static void pickout(PGconn *conn, Oid lobjId, int start, int len) { int lobj_fd; @@ -420,29 +750,28 @@ pickout(PGconn *conn, Oid lobjId, int start, int len) int nread; lobj_fd = lo_open(conn, lobjId, INV_READ); - if (lobj_fd < 0) - { - fprintf(stderr, "can't open large object %d\n", - lobjId); - } + if (lobj_fd < 0) + fprintf(stderr, "cannot open large object %u", lobjId); lo_lseek(conn, lobj_fd, start, SEEK_SET); buf = malloc(len + 1); nread = 0; - while (len - nread > 0) + while (len - nread > 0) { nbytes = lo_read(conn, lobj_fd, buf, len - nread); - buf[nbytes] = ' '; - fprintf(stderr, ">>> %s", buf); + buf[nbytes] = '\0'; + fprintf(stderr, ">>> %s", buf); nread += nbytes; + if (nbytes <= 0) + break; /* no more data? */ } free(buf); - fprintf(stderr, "\n"); + fprintf(stderr, "\n"); lo_close(conn, lobj_fd); } -void +static void overwrite(PGconn *conn, Oid lobjId, int start, int len) { int lobj_fd; @@ -451,36 +780,40 @@ overwrite(PGconn *conn, Oid lobjId, int start, int len) int nwritten; int i; - lobj_fd = lo_open(conn, lobjId, INV_READ); - if (lobj_fd < 0) - { - fprintf(stderr, "can't open large object %d\n", - lobjId); - } + lobj_fd = lo_open(conn, lobjId, INV_WRITE); + if (lobj_fd < 0) + fprintf(stderr, "cannot open large object %u", lobjId); lo_lseek(conn, lobj_fd, start, SEEK_SET); buf = malloc(len + 1); - for (i = 0; i < len; i++) + for (i = 0; i < len; i++) buf[i] = 'X'; - buf[i] = ' '; + buf[i] = '\0'; nwritten = 0; - while (len - nwritten > 0) + while (len - nwritten > 0) { nbytes = lo_write(conn, lobj_fd, buf + nwritten, len - nwritten); nwritten += nbytes; + if (nbytes <= 0) + { + fprintf(stderr, "\nWRITE FAILED!\n"); + break; + } } free(buf); - fprintf(stderr, "\n"); + fprintf(stderr, "\n"); lo_close(conn, lobj_fd); } + /* - * exportFile * export large object "lobjOid" to file "out_filename" + * exportFile - + * export large object "lobjOid" to file "out_filename" * */ -void +static void exportFile(PGconn *conn, Oid lobjId, char *filename) { int lobj_fd; @@ -490,45 +823,42 @@ exportFile(PGconn *conn, Oid lobjId, char *filename) int fd; /* - * create an inversion "object" + * open the large object */ lobj_fd = lo_open(conn, lobjId, INV_READ); - if (lobj_fd < 0) - { - fprintf(stderr, "can't open large object %d\n", - lobjId); - } + if (lobj_fd < 0) + fprintf(stderr, "cannot open large object %u", lobjId); /* * open the file to be written to */ - fd = open(filename, O_CREAT | O_WRONLY, 0666); - if (fd < 0) + fd = open(filename, O_CREAT | O_WRONLY | O_TRUNC, 0666); + if (fd < 0) { /* error */ - fprintf(stderr, "can't open unix file %s\n", + fprintf(stderr, "cannot open unix file\"%s\"", filename); } /* - * read in from the Unix file and write to the inversion file + * read in from the inversion file and write to the Unix file */ - while ((nbytes = lo_read(conn, lobj_fd, buf, BUFSIZE)) > 0) + while ((nbytes = lo_read(conn, lobj_fd, buf, BUFSIZE)) > 0) { tmp = write(fd, buf, nbytes); - if (tmp < nbytes) + if (tmp < nbytes) { - fprintf(stderr, "error while writing %s\n", + fprintf(stderr, "error while writing \"%s\"", filename); } } - (void) lo_close(conn, lobj_fd); - (void) close(fd); + lo_close(conn, lobj_fd); + close(fd); return; } -void +static void exit_nicely(PGconn *conn) { PQfinish(conn); @@ -547,7 +877,7 @@ main(int argc, char **argv) if (argc != 4) { - fprintf(stderr, "Usage: %s database_name in_filename out_filename\n", + fprintf(stderr, "Usage: %s database_name in_filename out_filename\n", argv[0]); exit(1); } @@ -562,57 +892,44 @@ main(int argc, char **argv) conn = PQsetdb(NULL, NULL, NULL, NULL, database); /* check to see that the backend connection was successfully made */ - if (PQstatus(conn) == CONNECTION_BAD) + if (PQstatus(conn) != CONNECTION_OK) { - fprintf(stderr, "Connection to database '%s' failed.\n", database); - fprintf(stderr, "%s", PQerrorMessage(conn)); + fprintf(stderr, "Connection to database failed: %s", + PQerrorMessage(conn)); exit_nicely(conn); } - res = PQexec(conn, "begin"); + res = PQexec(conn, "begin"); PQclear(res); - - printf("importing file %s\n", in_filename); + printf("importing file \"%s\" ...\n", in_filename); /* lobjOid = importFile(conn, in_filename); */ lobjOid = lo_import(conn, in_filename); -/* - printf("as large object %d.\n", lobjOid); + if (lobjOid == 0) + fprintf(stderr, "%s\n", PQerrorMessage(conn)); + else + { + printf("\tas large object %u.\n", lobjOid); - printf("picking out bytes 1000-2000 of the large object\n"); - pickout(conn, lobjOid, 1000, 1000); + printf("picking out bytes 1000-2000 of the large object\n"); + pickout(conn, lobjOid, 1000, 1000); - printf("overwriting bytes 1000-2000 of the large object with X's\n"); - overwrite(conn, lobjOid, 1000, 1000); -*/ + printf("overwriting bytes 1000-2000 of the large object with X's\n"); + overwrite(conn, lobjOid, 1000, 1000); - printf("exporting large object to file %s\n", out_filename); -/* exportFile(conn, lobjOid, out_filename); */ - lo_export(conn, lobjOid, out_filename); + 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)); + } - res = PQexec(conn, "end"); + res = PQexec(conn, "end"); PQclear(res); PQfinish(conn); - exit(0); + return 0; } +]]> - -