Re: another plperl bug

On Mon, Nov 22, 2004 at 06:37:46AM -0600, Andrew Dunstan wrote:
>
> 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);

This appears to happen with SETOF composite types, but not with
SETOF base types nor with a single row of a composite type -- would
that be consistent with your analysis?

I ran the following tests on 8.0.0beta5, which I think includes
Tom's latest changes:

CREATE OR REPLACE FUNCTION perl_set_int() RETURNS SETOF INTEGER AS $$
return [0..5];
$$ LANGUAGE plperl;

SELECT perl_set_int();
perl_set_int
--------------
0
1
2
3
4
5
(6 rows)

CREATE TYPE testrowperl AS (f1 integer, f2 text, f3 text);

CREATE OR REPLACE FUNCTION perl_row() RETURNS testrowperl AS $$
return {f2 => 'hello', f1 => 1, f3 => 'world'};
$$ LANGUAGE plperl;

SELECT perl_row();
perl_row
-----------------
(1,hello,world)
(1 row)

CREATE TYPE testsetperl AS (f1 integer, f2 text, f3 text);

CREATE OR REPLACE FUNCTION perl_set() RETURNS SETOF testsetperl AS $$
return [
{ f1 => 1, f2 => 'Hello', f3 => 'World' },
{ f1 => 2, f2 => 'Hello', f3 => 'PostgreSQL' },
{ f1 => 3, f2 => 'Hello', f3 => 'PL/Perl' }
];
$$ LANGUAGE plperl;

SELECT perl_set();
server closed the connection unexpectedly

--
Michael Fuhr
http://www.fuhr.org/~mfuhr/