Re: plperl.c patch to correctly support bytea inputs and output to functions and triggers. - Mailing list pgsql-bugs

From Theo Schlossnagle
Subject Re: plperl.c patch to correctly support bytea inputs and output to functions and triggers.
Date
Msg-id 9DFDB108-CA27-41E2-A8CD-7FDA9CD39AA8@omniti.com
Whole thread Raw
In response to Re: plperl.c patch to correctly support bytea inputs and output to functions and triggers.  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-bugs
On Apr 30, 2007, at 11:32 AM, Tom Lane wrote:

> Theo Schlossnagle <jesus@omniti.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)

I stand corrected.

>> 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)

Okay.  Not a bug.

I think that requiring a user to \ decode binary input is very very
expensive as well as having to \ encode it.  It seems wrong to me.

Are you interested in moving this patch to the feature queue?  I get
the impression you don't like the idea of making the bytea type work
more seamlessly in perl.  Perhaps I'm mistaken.

// Theo Schlossnagle
// Principal@OmniTI: http://omniti.com
// Esoteric Curio: http://www.lethargy.org/~jesus/

pgsql-bugs by date:

Previous
From: Kenneth Downs
Date:
Subject: Re: Plperl functions not re-entrant, wrong results
Next
From: "Phil Criley"
Date:
Subject: BUG #3258: Password fails, RPM installs in wrong directory