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



Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to