Alex Hunsaker <bada...@gmail.com> writes: > On Wed, Oct 12, 2011 at 15:33, Alex Hunsaker <bada...@gmail.com> wrote: >> On Wed, Oct 12, 2011 at 15:00, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> 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.
> PFA my attempt at a fix. > This gets rid of of most of the if/else chain and the has_retval crap > in plperl_handl_func(). Instead we let plperl_sv_to_datum() do most of > the lifting. It also now handles VOIDOID and checks that the request > result oid can be converted from the perl structure. For example if > you passed in a hashref with a result oid that was not an rowtype it > will error out with "PL/Perl cannot convert hash to non rowtype %s". > Arrays behave similarly. I'm working through this patch now. Does anyone object to having the array-to-non-array-result-type and hash-to-non-rowtype-result-type cases throw errors, rather than returning the rather useless ARRAY(...) and HASH(...) strings as pre-9.1 did? 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