[BUGS] plperl.c patch to correctly support bytea inputs and output to functions and triggers.

[Theo Schlossnagle]

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.

"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
// [EMAIL PROTECTED]: http://omniti.com
// Esoteric Curio: http://www.lethargy.org/~jesus/

The attached patch alters the code path for inputs and outputs with the BYTEAOID type.

plperl.c.diff
Description: Binary data

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
       choose an index scan if your joining column's datatypes do not
       match