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
