Re: plperl.c patch to correctly support bytea inputs and output to functions and triggers.

Theo Schlossnagle <jesus(at)omniti(dot)com> writes:
> As a note, the return from the function is a bytea, so no decoding is
> done. If I return a string with a \0 in it, then it will be clipped
> short. If I return a string with a "\\000" in it, I will get the
> four-character string \000. There is no way to correctly return a
> binary string that contains a \0 from plperl as it stands.

That is simply incorrect.

regression=# create or replace function foo() returns bytea as $$
return 'foo\000bar';
$$ language plperl;
CREATE FUNCTION
regression=# select foo();
foo
------------
foo\000bar
(1 row)

regression=# select length(foo());
length
--------
7
(1 row)

> There should be no escaping required to return a bytea from within a pl
> in postgres.

That's not a bug report, that's a proposal for a non-backward-compatible
behavioral change. pgsql-bugs is not the forum for such proposals.
If you want to take it up in pgsql-hackers, be prepared to answer
questions about why bytea should behave differently from all other
types, and what about bytea members of arrays and records, and what
about consistency with the other PLs?

> If I have a binary passthrough function in plperl,
> it should just work:

> create function pl_passthru(bytea) returns bytea as $$
> return $_[0];
> $$ language plperl;

Worksforme.

regression=# select pl_passthru(E'foo\\000bar'::bytea);
pl_passthru
-------------
foo\000bar
(1 row)

regression=# select length(pl_passthru(E'foo\\000bar'::bytea));
length
--------
7
(1 row)

regards, tom lane