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: 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 13:30:22
Message-ID: 4635EF6E.1050104@omniti.com (view raw or flat)
Thread:
Lists: pgsql-bugs
Tom Lane wrote:
> Theo Schlossnagle <jesus(at)omniti(dot)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(at)OmniTI: http://omniti.com
// Esoteric Curio: http://www.lethargy.org/~jesus/

In response to

Responses

pgsql-bugs by date

Next:From: Kenneth DownsDate: 2007-04-30 13:37:35
Subject: Plperl functions not re-entrant, wrong results
Previous:From: Magnus HaganderDate: 2007-04-30 10:26:11
Subject: Re: BUG #3059: psql to 'postgres' shortcut

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