Large object API problems

From: Aaron Hillegass <aaron(at)bignerdranch(dot)com>
To: pgsql-bugs(at)postgresql(dot)org
Cc: Chris Campbell <chris(at)bignerdranch(dot)com>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Subject: Large object API problems
Date: 2004-07-14 18:53:50
Message-ID: 24E395E6-D5C7-11D8-B1BC-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:

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.

Browse pgsql-bugs by date

  From Date Subject
Next Message Bruce Momjian 2004-07-15 03:29:11 Re: SELECT DISTINCT on boxes
Previous Message Bruce Momjian 2004-07-14 17:03:26 SELECT DISTINCT on boxes