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 [EMAIL PROTECTED])
