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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

Browse pgsql-bugs by date

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