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.
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 |