Re: lo_create(oid, bytea) breaks every extant release of libpq - Mailing list pgsql-hackers

From Noah Misch
Subject Re: lo_create(oid, bytea) breaks every extant release of libpq
Date
Msg-id 20140612180505.GC686905@tornado.leadboat.com
Whole thread Raw
In response to Re: lo_create(oid, bytea) breaks every extant release of libpq  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: lo_create(oid, bytea) breaks every extant release of libpq  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Thu, Jun 12, 2014 at 01:53:19PM -0400, Tom Lane wrote:
> 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.

Sounds good.

> 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?

The pg_upgrade test suite covers this well.

> 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.

I agree all the above make sense for 9.4.  I also wouldn't object to a
hardening of lo_initialize() sneaking in at this stage.

Thanks,
nm

-- 
Noah Misch
EnterpriseDB                                 http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Keith Fiske
Date:
Subject: Re: [GENERAL] Question about partial functional indexes and the query planner
Next
From: Noah Misch
Date:
Subject: Re: updated emacs configuration