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/
