Re: another plperl bug - Mailing list pgsql-hackers

From Tom Lane
Subject Re: another plperl bug
Date
Msg-id 27467.1101227842@sss.pgh.pa.us
Whole thread Raw
In response to Re: another plperl bug  (Michael Fuhr <mike@fuhr.org>)
Responses Re: another plperl bug  (Michael Fuhr <mike@fuhr.org>)
Re: another plperl bug  (Richard Poole <rp@guests.deus.net>)
List pgsql-hackers
Michael Fuhr <mike@fuhr.org> writes:
> How far do you want to go with checking return types?  Some of the
> following test cases are approaching "garbage in, garbage out"
> territory and I don't know how much effort you want to put into
> protecting programmers from themselves.  Some of the cases already
> raise errors; for consistency I'm inclined to think they all should.

I think all these cases are actually OK as-is.

> CREATE FUNCTION test1() RETURNS TEXT AS $$
> return ["test"];
> $$ LANGUAGE plperl;

> SELECT test1();
>       test1       
> ------------------
>  ARRAY(0x8427a58)
> (1 row)

This is exactly what Perl will do if you try to coerce an array to a
scalar:

$ perl -e 'print ["test 1"], "\n"'
ARRAY(0xa03ec28)
$

so I don't think a Perl programmer would find it surprising; if anything
he'd probably complain if we *didn't* do that.

I would add these test cases to the regression test were it not that the
addresses are machine-dependent...
        regards, tom lane


pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: Beta5 now Available
Next
From: "Marc G. Fournier"
Date:
Subject: Re: Beta5 now Available