Re: another plperl bug

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Michael Fuhr <mike(at)fuhr(dot)org>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: another plperl bug
Date: 2004-11-23 16:37:22
Message-ID: 27467.1101227842@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

Michael Fuhr <mike(at)fuhr(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Marc G. Fournier 2004-11-23 16:48:21 Re: Beta5 now Available
Previous Message David Fetter 2004-11-23 16:37:09 Re: Beta5 now Available

Browse pgsql-patches by date

  From Date Subject
Next Message Karel Zak 2004-11-23 16:58:01 pg_dumplo schema support
Previous Message Peter Eisentraut 2004-11-23 16:28:26 Re: htmlhelp generation