This is part of The Pile, a partial archive of some open source mailing lists and newsgroups.
Subject: DBD::Pg: lo_write doesn't rewrite
From: Honza Pazdziora <adelton@informatics.muni.cz>
Date: Thu, 17 Aug 2000 11:45:09 +0200
Hello,
I've hit a couple of issues in PostgreSQL's blob support.
The following code
use DBI;
my $dbh = DBI->connect('dbi:Pg:dbname=template1', undef, undef,
{ RaiseError => 1 });
$dbh->{'AutoCommit'} = 0;
my $RW = ($dbh->{pg_INV_WRITE} | $dbh->{pg_INV_READ});
my $lob_id = $dbh->func($RW, 'lo_creat');
my $lob_fd = $dbh->func($lob_id, $RW, 'lo_open');
$dbh->func($lob_fd, pack('c*', 1, 2), 2, 'lo_write'); ### [1]
$dbh->commit;
$lob_fd = $dbh->func($lob_id, $RW, 'lo_open');
$dbh->func($lob_fd, pack('c*', 3, 4, 5), 3, 'lo_write'); ### [2]
my $buffer;
local $^W = 0;
$dbh->func($lob_fd, 0, 0, 'lo_lseek');
my $read = $dbh->func($lob_fd, $buffer, 3, 'lo_read');
print "Read $read; got ", unpack('c*', $buffer), "\n";
__END__
Read 3; got 125
seems to suggest that lo_write won't rewrite the existing data in
the blob. I thought that the result would be 345. Is it correct that
in order to update the content of the blob, one has to create a new
one and fill it from the scratch?
Since DBD::Pg 0.95 doesn't support lo_unlink, I assume these objects
will be filling up the database with no chance to get them released,
is that correct? Edmund, would you like a patch that'd add lo_unlink
to DBD::Pg?
Also, if I change the code between [1] and [2] to
$dbh->func($lob_fd, pack('c*', 1, 2), 2, 'lo_write');
$dbh->func($lob_fd, 0, 0, 'lo_lseek');
$dbh->func($lob_fd, pack('c*', 3, 4, 5), 3, 'lo_write');
not finishing the transaction and adding second lo_write, the answer is
Read ; got
Is this an issue with Perl or is this the correct behaviour of the
PostgreSQL itself? All the call previous to lo_read return defined
values, the lo_read is the first one to fail.
I'm using 5.6.0 patched upto end of June, 1.13, 0.95 and 7.0.2.
===