I've found a bug with the way plperl/plperlu handles bytea types. It
fails to correctly handle bytea binary inputs and outputs. Perl
scalars are wrongly treated as C strings when a the source or
destination tuple in postgres is of type bytea.
The attached patch alters the code path for inputs and outputs with
the BYTEAOID type.
"Works for me"
==== begin plperl_bytea.sql ====
create or replace function pl_octet_length(bytea) returns integer as $$
return length($_[0]);
$$ language plperl;
create or replace function pl_produce_bytea() returns bytea as $$
return "\0\0\0\0\0\0see me?";
$$ language plperl;
==== end plperl_bytea.sql ===
PROBLEM:
pltest=# select pl_octet_length(E'\012\015'), octet_length(E'\012\015');
pl_octet_length | octet_length
-----------------+--------------
8 | 2
(1 row)
pltest=# select pl_produce_bytea(), octet_length(pl_produce_bytea());
pl_produce_bytea | octet_length
------------------+--------------
| 0
(1 row)
AFTER PATCH:
pltest=# select pl_octet_length(E'\012\015'), octet_length(E'\012\015');
pl_octet_length | octet_length
-----------------+--------------
2 | 2
(1 row)
pltest=# select pl_produce_bytea(), octet_length(pl_produce_bytea());
pl_produce_bytea | octet_length
---------------------------------+--------------
\000\000\000\000\000\000see me? | 13
(1 row)
// Theo Schlossnagle
// Principal@OmniTI: http://omniti.com
// Esoteric Curio: http://www.lethargy.org/~jesus/
