I wrote:
> Alvaro Herrera <alvherre@2ndquadrant.com> writes:
>> I was also going to suggest lo_create_bytea(). Another similar
>> possibility would be lo_from_bytea() -- or, since we have overloading
>> (and we can actually use it in this case without breaking libpq), we
>> could just have lo_from(oid, bytea).
> Andres also mentioned lo_from_bytea(), and I kinda like it too.
> I don't like plain lo_from(), as it's not too apparent what it's
> supposed to get data "from" --- someone might think the second
> parameter was supposed to be a file name a la lo_import(),
> for example.
Since the discussion seems to have trailed off, I'm going to run with
lo_from_bytea(). The plan is:
1. Rename the function.
2. Add an opr_sanity regression test memorializing what we should get
from lo_initialize()'s query.
3. Make sure that the regression tests leave behind a few large objects,
so that testing of pg_dump/pg_restore using the regression database
will exercise the large-object code paths.
It'd be a good thing if the TAP tests for client programs included
testing of pg_dump/pg_restore, but that's a bit beyond my competence
with that tool ... anyone care to step up?
Redoing or getting rid of lo_initialize()'s query would be a good thing
too; but that does not seem like material for back-patching into 9.4,
while I think all the above are.
regards, tom lane
