From: | Noah Misch <noah(at)leadboat(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: lo_create(oid, bytea) breaks every extant release of libpq |
Date: | 2014-06-12 04:54:36 |
Message-ID: | 20140612045436.GA691783@tornado.leadboat.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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().
Thanks,
nm
--
Noah Misch
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2014-06-12 05:01:49 | Re: lo_create(oid, bytea) breaks every extant release of libpq |
Previous Message | Noah Misch | 2014-06-12 04:38:36 | Re: Something flaky in the "relfilenode mapping" infrastructure |