Re: pl/perl example in the doc no longer works in 9.1
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: "David E. Wheeler" <david@kineticode.com>
Cc: Amit Khandekar <amit.khandekar@enterprisedb.com>, hackers@postgresql.org, Alvaro Herrera <alvherre@commandprompt.com>, Alexey Klyukin <alexk@commandprompt.com>, Alex Hunsaker <badalex@gmail.com>
Date: 2011-10-12T21:00:16Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Convert Postgres arrays to Perl arrays on PL/perl input arguments
- 87bb2ade2ce6 9.1.0 cited
"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 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