Hello
2013/10/21 Andrew Dunstan <and...@dunslane.net> > > 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 >> > 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 c0d5be5d6a736d2ee8141e920bc3de**8e001bf6d9 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 >
