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/