Skip site navigation (1) Skip section navigation (2)

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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Theo Schlossnagle <jesus(at)omniti(dot)com>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: plperl.c patch to correctly support bytea inputs and output to functions and triggers.
Date: 2007-04-30 15:32:48
Message-ID: 27572.1177947168@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-bugs
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

In response to

Responses

pgsql-bugs by date

Next:From: Tom LaneDate: 2007-04-30 15:56:26
Subject: Re: Plperl functions not re-entrant, wrong results
Previous:From: Kenneth DownsDate: 2007-04-30 13:44:04
Subject: Plperl functions not re-entrant, wrong results

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group