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 по дате отправления: