Tom Lane <tgl@sss.pgh.pa.us> writes:
> 6.5.* only allows large objects to be kept open within a single
> transaction; you have to wrap BEGIN...END around anything that involves
> lo_open ... lo_read/write ... lo_close. In particular, since lo_import
> and lo_export are just such sequences, they need to be called inside
> a transaction.
Note that the Perl interface to large objects is broken in both 6.4.2
and 6.5.1, in that a BLOB containing a NUL character will be truncated
at the first NUL when read back using the Perl lo_read method. I have
reported this problem both to this list and via various other channels
over the past few months, but I just checked the CVS repository and
there is still no fix there.
For what it is worth, in case anyone reading this wants to either fix
their own copies or better yet fix the main source repository, the
necessary patch is simply:
======cut=here========================================================
--- perl5/Pg.xs Sat Aug 14 12:46:35 1999
+++ perl5.fixed/Pg.xs Sun Oct 3 14:00:35 1999
@@ -1,6 +1,6 @@
/*-------------------------------------------------------
*
- * $Id: Pg.xs,v 1.12 1999/02/19 23:27:17 tgl Exp $
+ * $Id: Pg.xs,v 1.12 1999/02/19 23:27:17 tgl Exp $ (NUL bug patched)
*
* Copyright (c) 1997, 1998 Edmund Mergl
*
@@ -643,7 +643,7 @@
}
OUTPUT:
RETVAL
- buf
+ buf sv_setpvn((SV*)ST(2), buf, RETVAL);
int
lo_write(conn, fd, buf, len)
@@ -1029,7 +1029,7 @@
}
OUTPUT:
RETVAL
- buf
+ buf sv_setpvn((SV*)ST(2), buf, RETVAL);
int
======cut=here========================================================
For the curious, this makes Perl set the length of the returned
scalar to be the size returned by the library lo_read() call, instead
of using C's strlen() function to work out the length.
Hope this helps someone,
Doug.
