Tom Lane wrote:
> Theo Schlossnagle <jesus@omniti.com> writes:
>> If I return a bytes from perl that looks like: "hello\0there",
>> postgres sees a 5 byte string "hello".
>
> You have failed to pay any attention to the escaping rules for bytea if
> you do that.
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.
There should be no escaping required to return a bytea from within a pl
in postgres. It would mean that when I have a 20MB binary column, I
would have to use up to four times that space just to return it into the
callers context. That would be a bug in its own right. I certainly
don't want to have to convert a binary blob into an escaped version to
hand it back from within the database -- that couldn't possible be a
"desired" use pattern.
As I see it, bytea *are* special. They are treated specially in other
portions of postgres (where SendFunctionCall is used over
OuputFunctionCall). 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;
That function should give me back what I passed it. At least from a
type defined equality standpoint. I'd argue that any function in any pl
should satisfied that reflexive property. Simply returning the passed
argument should not alter it assuming the input and output types are the
same.
While I realize that each pl has its nuances a type conversion from:
pg2pl(A) pl2pg(A)
postgrestype(A) -> pltype(A) -> postgrestype(A)
I would make the assumption when using a pl that: pl2pg(pg2pl(A)) === A
If there was escaping required to make this so, I would hope that the pl
implementation would do that for me.
I'm not sure I follow the argument against the patch. As it stands,
bytea type is supported by plperl (I am allowed to create functions with
both input and output types of bytea. Both input and output of bytea
are broken. The patch fixes that. The only argument I could see
against the patch would be if there were other types that also required
this special treatment. Are there?
--
// Theo Schlossnagle
// Principal@OmniTI: http://omniti.com
// Esoteric Curio: http://www.lethargy.org/~jesus/
