I wrote: > Alvaro Herrera <alvhe...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers