Noah Misch n...@leadboat.com 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
On 2014-06-12 10:48:01 -0400, Tom Lane wrote:
Noah Misch n...@leadboat.com 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
Tom Lane wrote:
Noah Misch n...@leadboat.com 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
On Thu, Jun 12, 2014 at 10:56 AM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Tom Lane wrote:
Noah Misch n...@leadboat.com 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
Alvaro Herrera alvhe...@2ndquadrant.com 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),
Lo_from_bytea sounds me better than lo_create_bytea
Robert Haas robertmh...@gmail.com 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
I wrote:
Alvaro Herrera alvhe...@2ndquadrant.com 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,
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
Noah Misch n...@leadboat.com 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
On Thu, Jun 12, 2014 at 02:53:23PM -0400, Tom Lane wrote:
Noah Misch n...@leadboat.com 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
I wrote:
Robert Haas robertmh...@gmail.com 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
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
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 which
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
2014-06-12 6:22 GMT+02:00 Tatsuo Ishii is...@postgresql.org:
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
Noah Misch n...@leadboat.com 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
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.
2014-06-12 7:08 GMT+02:00 Tom Lane t...@sss.pgh.pa.us:
Noah Misch n...@leadboat.com 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?
19 matches
Mail list logo
