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  (Michael Fuhr <mike@fuhr.org>)
Re: another plperl bug  (Richard Poole <rp@guests.deus.net>)
Список 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 по дате отправления:

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: Beta5 now Available
Следующее
От: "Marc G. Fournier"
Дата:
Сообщение: Re: Beta5 now Available