I wrote:
> Robert Haas writes:
>> Presumably we should also fix libpq to not be so dumb. I mean, it
>> doesn't help with the immediate problem, since as you say there could
>> be non-upgraded copies of libpq out there for the indefinite future,
>> but it still seems like something we oughta fix.
On Thu, Jun 12, 2014 at 02:53:23PM -0400, Tom Lane wrote:
> Noah Misch writes:
> > On Thu, Jun 12, 2014 at 01:53:19PM -0400, Tom Lane wrote:
> >> 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 t
Noah Misch writes:
> On Thu, Jun 12, 2014 at 01:53:19PM -0400, Tom Lane wrote:
>> 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 co
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
I wrote:
> Alvaro Herrera 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 al
Robert Haas writes:
> Presumably we should also fix libpq to not be so dumb. I mean, it
> doesn't help with the immediate problem, since as you say there could
> be non-upgraded copies of libpq out there for the indefinite future,
> but it still seems like something we oughta fix.
It's been in t
Lo_from_bytea sounds me better than lo_create_bytea
Alvaro Herrera writes:
> Tom Lane wrote:
>> Any other votes out there?
> 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
On Thu, Jun 12, 2014 at 10:56 AM, Alvaro Herrera
wrote:
> Tom Lane wrote:
>> Noah Misch writes:
>> >> lo_new() or lo_make()? An earlier draft of the patch that added
>> >> lo_create(oid, bytea) had a similar function named make_lo().
>>
>> It appears that lo_make() has a small plurality, but bef
Tom Lane wrote:
> Noah Misch writes:
> >> lo_new() or lo_make()? An earlier draft of the patch that added
> >> lo_create(oid, bytea) had a similar function named make_lo().
>
> It appears that lo_make() has a small plurality, but before we lock
> that name in, there was one other idea that occur
On 2014-06-12 10:48:01 -0400, Tom Lane wrote:
> Noah Misch writes:
> >> lo_new() or lo_make()? An earlier draft of the patch that added
> >> lo_create(oid, bytea) had a similar function named make_lo().
>
> It appears that lo_make() has a small plurality, but before we lock
> that name in, there
Noah Misch writes:
>> lo_new() or lo_make()? An earlier draft of the patch that added
>> lo_create(oid, bytea) had a similar function named make_lo().
It appears that lo_make() has a small plurality, but before we lock
that name in, there was one other idea that occurred to me: the
underlying C
2014-06-12 7:08 GMT+02:00 Tom Lane :
> Noah Misch writes:
> > On Wed, Jun 11, 2014 at 11:57:20PM -0400, Tom Lane wrote:
> >> 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
2014-06-12 6:54 GMT+02:00 Noah Misch :
> 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
Noah Misch writes:
> On Wed, Jun 11, 2014 at 11:57:20PM -0400, Tom Lane wrote:
>> 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_creat
2014-06-12 6:22 GMT+02:00 Tatsuo Ishii :
> > Meanwhile, we have to either revert the addition of lo_create(oid,
> > bytea) altogether, or choose a different name for it. Suggestions?
>
> I wonder if there's any use case where we need to store bytea into
> large objects. Don't we already have byte
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 l
> Meanwhile, we have to either revert the addition of lo_create(oid,
> bytea) altogether, or choose a different name for it. Suggestions?
I wonder if there's any use case where we need to store bytea into
large objects. Don't we already have bytea data type? If the use case
is for large data whic
While investigating a different issue, I was astonished to find that
pg_restore in HEAD is incapable of restoring dumps containing large
objects: it fails with messages like
pg_restore: [archiver] could not create large object 10: ERROR: function
call message contains 1 arguments but functio
19 matches
Mail list logo
