Re: arrays as pl/perl input arguments [PATCH]
От | Alex Hunsaker |
---|---|
Тема | Re: arrays as pl/perl input arguments [PATCH] |
Дата | |
Msg-id | AANLkTi=ih1Ehy3nUTf3zTqkxZkENmxZgyAyETnrozDXy@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: arrays as pl/perl input arguments [PATCH] (Alexey Klyukin <alexk@commandprompt.com>) |
Ответы |
Re: arrays as pl/perl input arguments [PATCH]
Re: arrays as pl/perl input arguments [PATCH] |
Список | pgsql-hackers |
On Tue, Feb 8, 2011 at 08:18, Alexey Klyukin <alexk@commandprompt.com> wrote: > > On Feb 6, 2011, at 9:43 AM, Alex Hunsaker wrote: >> So here is a v6 >> .... >> Comments? > > Thanks, looks great to me. It passes all the tests on my OS X system. I wonder > what's the purpose of the amagic_call in get_perl_array_ref, instead of > calling newRV_noinc on the target SV * ? Well, you can't AV *av = (AV *)SvRV(sv); And the SV * amagic_call returns is already a reference, so the newRV_noinc() would be redundant no? It occurs to me instead of doing the amagic_call we could just call the to_array method directly using perl_call_pv(). That would look more normal and less magic-- thats probably a good thing? > Also, in array_to_datum (line 1050), if get_perl_array_ref returns NULL for > the first element of the corresponding dimension, but non-NULL for the second > one - it would use uninitialized dims[cur_depth] value in comparison (which, > although, would probably lead to the desired comparison result). Good catch, will fix. All of those checks should be outside of the while loop. While Im at it Ill also rebase against HEAD (im sure there will be some conflicts with that other plperl patch that just went in ;)).
В списке pgsql-hackers по дате отправления: