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
should be - it is more consistent with current API than my proposal.
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 for including to core - we have no buildin SQL functions that allows access simple and fast access on binary level. Next - these functions completes lo functionality.
Other questions - should be these functions propagated to libpq? and who will write patch? You or me?
Regards
Pavel
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. :-)
