Re: proposal: lob conversion functionality

Hello

2013/10/21 Andrew Dunstan <andrew(at)dunslane(dot)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
>