I've been using large objects in PostgreSQL in two applications, and
I've found a couple things about the API frustrating:

0) In "Oid lo_creat(PGconn *conn, int mode)," why is there a mode on
lo_create? The mode is determined when the object is lo_open()ed,
right?

(By the way, the example in the docs has the wrong number of arguments:
"inv_oid = lo_creat(INV_READ|INV_WRITE);")

1) There is no lo_truncate(PGconn *conn, int fd, off_t len).

Using lo_write, I can change an existing large object, but I can't
make it shorter. In practice, this means that I never edit existing
objects -- I just lo_unlink the old one and lo_creat a new one.

2) There is no lo_length(PGconn *conn, int fd).

I often need a buffer big enough to hold the large object, and it would
be nice if there were a function that would tell me that size of the
large object (as a size_t). Sure, I can use lo_lseek to jump to the
end, and then use lo_lseek to jump back to the beginning, but the
resulting code is more awkward than one would wish:

int length = lo_lseek(theConnection, fd, 0, SEEK_END);
lo_lseek(theConnection, fd, 0, SEEK_SET);
char *data = (char *)malloc(length);
int rlength = lo_read(theConnection, fd, data, length);

I could also read the the large object in bite-sized chunks, but this
also has trade-offs.

Overall, I've been very happy with the performance and reliability of
large objects, and, clearly, there are workarounds for these
shortcomings. Is it recommended that I begin to move away from large
objects and start using bytea directly whenever possible?

Best wishes,
Aaron Hillegass
Big Nerd Ranch, Inc.


---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majordomo (AT) postgresql (DOT) org)