Large object API problems

From: Aaron Hillegass <aaron(at)bignerdranch(dot)com>
To: bugs(at)postgresql(dot)org
Cc: Chris Campbell <chris(at)bignerdranch(dot)com>
Subject: Large object API problems
Date: 2004-04-27 13:07:11
Message-ID: CBD6D2BA-984B-11D8-8AF0-000A95A0A0F0@bignerdranch.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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.

Browse pgsql-bugs by date

  From Date Subject
Next Message Nicholas Howell 2004-04-27 14:34:38 Query producing the wrong results?
Previous Message Bruce Momjian 2004-04-27 13:04:24 Re: [BUGS] BUG #1134: ALTER USER ... RENAME breaks md5