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

From Pavel Stehule
Subject Re: lo_create(oid, bytea) breaks every extant release of libpq
Date
Msg-id CAFj8pRCEB6i+9sAxhgtgQArSDRD7O52T2qHKjp9Ps2ewQFMwUA@mail.gmail.com
Whole thread Raw
In response to Re: lo_create(oid, bytea) breaks every extant release of libpq  (Noah Misch <noah@leadboat.com>)
List pgsql-hackers



2014-06-12 6:54 GMT+02:00 Noah Misch <noah@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

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: lo_create(oid, bytea) breaks every extant release of libpq
Next
From: Tom Lane
Date:
Subject: Re: Something flaky in the "relfilenode mapping" infrastructure