Re: another plperl bug
| От | Tom Lane |
|---|---|
| Тема | Re: another plperl bug |
| Дата | |
| Msg-id | 27467.1101227842@sss.pgh.pa.us обсуждение |
| Ответ на | Re: another plperl bug (Michael Fuhr <mike@fuhr.org>) |
| Ответы |
Re: another plperl bug
Re: another plperl bug |
| Список | 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 по дате отправления: