Re: pl/perl example in the doc no longer works in 9.1
От | Tom Lane |
---|---|
Тема | Re: pl/perl example in the doc no longer works in 9.1 |
Дата | |
Msg-id | 29540.1318453216@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: pl/perl example in the doc no longer works in 9.1 ("David E. Wheeler" <david@kineticode.com>) |
Ответы |
Re: pl/perl example in the doc no longer works in 9.1
|
Список | pgsql-hackers |
"David E. Wheeler" <david@kineticode.com> writes: > On Oct 12, 2011, at 9:15 AM, Tom Lane wrote: >> Well, the real question is why a function declared to return VOID cares >> at all about what the last command in its body is. If this has changed >> since previous versions then I think it's a bug and we should fix it, >> not just change the example. > It has indeed changed, either in 9.0 or 9.1 (the latter, I think). I had to add a bunch of bare return statements to existingfunctions. This appears to have gotten broken in commit 87bb2ade2ce646083f39d5ab3e3307490211ad04, which changed the function return code to go through plperl_sv_to_datum, which is making unwarranted assumptions ... but since it's utterly bereft of comments, it's hard for a non Perl hacker to identify exactly what it should do instead. The core of the problem seems to be that if SvROK(sv) then the code assumes that it must be intended to convert that to an array or composite, no matter whether the declared result type of the function is compatible with such a thing. So I think this probably broke not only VOID-result cases, but also cases where a Perl array or hash is supposed to be returned as, say, text. It would be more appropriate to drive the cases off the nature of the function result type, perhaps. regards, tom lane
В списке pgsql-hackers по дате отправления: