Re: bytea corruption?

From: Tim Landscheidt <tim(at)tim-landscheidt(dot)de>
To: pgsql-general(at)postgresql(dot)org
Subject: Re: bytea corruption?
Date: 2009-08-21 23:11:07
Message-ID: m3praorcdw.fsf@passepartout.tim-landscheidt.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Nathan Jahnke <njahnke(at)gmail(dot)com> wrote:

> [...]
> my $encodeddata = $data;
> $encodeddata =~ s!(\\|[^ -~])!sprintf("\\%03o",ord($1))!ge; #prepare
> data for bytea column storage

> [...]

> my $insert_sth = $connection->prepare('insert into testtable (data)
> values (?) returning id');
> $insert_sth->execute($encodeddata);
> my $ref = $insert_sth->fetchrow_hashref;
> my $id = $ref->{id};

> my $getall_sth = $connection->prepare('select * from testtable where id=?');
> $getall_sth->execute($id);
> my $newref = $getall_sth->fetchrow_hashref;
> my $newdata = $newref->{data};
> $newdata =~ s!\\(?:\\|(\d{3}))!$1 ? chr(oct($1)) : "\\"!ge; #decode
> bytea column storage format
> [...]

> hash of data changes ... if you uncomment the $data = '123abc' line
> you can see that it works with those six bytes fine, and it also works
> with most other binary data, just not this binary data. any insight
> would be appreciated. thanks.

Why do you encode/decode the data in your own application a
second time? It is already encoded by DBD::Pg.

Tim

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Arturo Pérez 2009-08-22 01:06:37 Re: Problem with bacula and 8.3/8.4
Previous Message Alban Hertroys 2009-08-21 22:23:49 Re: Comparing arrays of composite types