good catch - it's because i'm used to working in plperlu.
unfortunately commenting out those lines makes no difference for this
particular data (that i linked in my original email); it's still
corrupted:
# ./bytea.pl
37652cf91fb8d5e41d3a90ea3a22ea61 != ce3fc63b88993af73fb360c70b7ec965
nathan
On Fri, Aug 21, 2009 at 6:11 PM, Tim Landscheidt<tim@tim-landscheidt.de> wrote:
> Nathan Jahnke <njahnke@gmail.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
>
>
> --
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
>