2014-06-12 6:54 GMT+02:00 Noah Misch <n...@leadboat.com>: > On Wed, Jun 11, 2014 at 11:57:20PM -0400, Tom Lane wrote: > > While there's certainly a good argument to be made for making > > lo_initialize do that query differently, there's no way that we > > can fix every copy of libpq that's in the field. I think we have to > > consider that "there can be only one lo_create" is effectively part of > > the protocol spec for the foreseeable future. (It'd be easy enough > > to add a check in the opr_sanity regression test to catch violations > > of this rule.) > > > > It's also extremely unfortunate that the regression tests don't > > create (or at least don't leave behind) any large objects, as we > > might then have possibly caught this bug much earlier. > > Agreed. > > > Meanwhile, we have to either revert the addition of lo_create(oid, > > bytea) altogether, or choose a different name for it. Suggestions? > > lo_new() or lo_make()? An earlier draft of the patch that added > lo_create(oid, bytea) had a similar function named make_lo(). >
+1 for lo_new Regards Pavel > > Thanks, > nm > > -- > Noah Misch > EnterpriseDB http://www.enterprisedb.com > > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers >
