Re: pl/perl example in the doc no longer works in 9.1
От | Alexey Klyukin |
---|---|
Тема | Re: pl/perl example in the doc no longer works in 9.1 |
Дата | |
Msg-id | 123C7889-BCE1-467F-A678-E8ACE9363720@commandprompt.com обсуждение исходный текст |
Ответ на | Re: pl/perl example in the doc no longer works in 9.1 (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On Oct 13, 2011, at 9:02 PM, Tom Lane wrote: > Alex Hunsaker <badalex@gmail.com> writes: >> On Wed, Oct 12, 2011 at 15:33, Alex Hunsaker <badalex@gmail.com> wrote: >>> On Wed, Oct 12, 2011 at 15:00, Tom Lane <tgl@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? No objections here. -- Alexey Klyukin http://www.commandprompt.com The PostgreSQL Company – Command Prompt, Inc.
В списке pgsql-hackers по дате отправления: