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

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

From: Theo Schlossnagle <jesus(at)omniti(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Theo Schlossnagle <jesus(at)omniti(dot)com>, 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 16:05:05
Message-ID: 9DFDB108-CA27-41E2-A8CD-7FDA9CD39AA8@omniti.com (view raw or flat)
Thread:
Lists: pgsql-bugs
On Apr 30, 2007, at 11:32 AM, Tom Lane wrote:

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

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(at)OmniTI: http://omniti.com
// Esoteric Curio: http://www.lethargy.org/~jesus/


In response to

pgsql-bugs by date

Next:From: Kenneth DownsDate: 2007-04-30 16:12:11
Subject: Re: Plperl functions not re-entrant, wrong results
Previous:From: Phil CrileyDate: 2007-04-30 16:03:36
Subject: BUG #3258: Password fails, RPM installs in wrong directory

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