On 10/20/2013 07:52 PM, Noah Misch wrote:
Consider this list of new functions in their place:
lo_create(oid, bytea) RETURNS oid -- new LO with content (similar to make_lo)
lo_get(oid) RETURNS bytea -- read entire LO (same as
load_lo)
lo_get(oid, bigint, int) RETURNS bytea -- read from offset for length
lo_put(oid, bigint, bytea) RETURNS void -- write data at offset
Anything we do here effectively provides wrappers around the existing
functions tailored toward the needs of libpq. A key outstanding question is
whether doing so provides a compelling increment in usability. On the plus
side, adding such functions resolves the weirdness of having a variety of
database object that is easy to access from libpq but awkward to access from
plain SQL. On the minus side, this could easily live as an extension module.
I have not used the large object facility to any significant degree, but I
generally feel this is helpful enough to justify core inclusion. Any other
opinions on the general suitability or on the specifics of the API offered?
I am currently working with a client on a largeish LO migration. I would
certainly have appreciated having lo_get(oid) available - I wrote
something in plpgsql that did almost exactly what Pavel's code does.
Your additional lo_get(oid, offset, length) and lo_put(oid, offset,
bytea) seem sane enough. So +1 from me for adding all these.
If we're going to be doing work in this area, let me note that I'm not
sure the decision in commit c0d5be5d6a736d2ee8141e920bc3de8e001bf6d9 to
have pg_dump write a separate archive entry for each LO was the wisest
decision we ever made. My client is currently migrating to use of bytea
instead of LOs partly because we didn't want to think about the issue of
having hundreds of millions of archive entries in a dump. When that
process is complete we'll upgrade. :-)
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
