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