Re: another plperl bug - Mailing list pgsql-hackers

From Tom Lane
Subject Re: another plperl bug
Date
Msg-id 18139.1101155906@sss.pgh.pa.us
Whole thread Raw
In response to another plperl bug  ("Andrew Dunstan" <andrew@dunslane.net>)
List pgsql-hackers
"Andrew Dunstan" <andrew@dunslane.net> writes:
> I discovered a further plperl bug last night. If foo() is a SRF and
> therefore returns an arrayref, calling select foo() rather than select *
> from foo() causes a segfault because this line passes NULL as the argument:

>     tupdesc = CreateTupleDescCopy(rsinfo->expectedDesc);

While looking into this I discovered another serious shortcoming: the
code was using static variables to process SETOF results, which of
course would break completely in any query involving more than one
plperl SETOF function.  I also realized that the ret_hv code we were
concerned about was actually dead code, because there's a test further
up that insists that the Perl result be an array when the function is
declared to return set.  So I wiped out that whole code path, for a nice
improvement in code size and legibility...
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: another plperl bug
Next
From: Oliver Jowett
Date:
Subject: Re: 64Bit Solaris Compile