"David E. Wheeler" <da...@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 existing functions.
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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
