Large object API problems - Mailing list pgsql-bugs

From Aaron Hillegass
Subject Large object API problems
Date
Msg-id CBD6D2BA-984B-11D8-8AF0-000A95A0A0F0@bignerdranch.com
Whole thread Raw
List pgsql-bugs
I've been using large objects in PostgreSQL in two applications, and
I've found a couple things about the API frustrating:

1) There is no lo_truncate(PGconn *conn, size_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);

Overall, I've been very happy with the performance and reliability of
large objects, and, clearly, there are workarounds for these
shortcomings.  It would be nice if every programmer didn't have to
figure them out.

Best wishes,
Aaron Hillegass
Big Nerd Ranch, Inc.

pgsql-bugs by date:

Previous
From: "C9 Developer"
Date:
Subject: Bug in functions returning setof where table has dropped column
Next
From: "Bruno Necchi"
Date:
Subject: Problems....