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]  (Alex Hunsaker <badalex@gmail.com>)
Re: arrays as pl/perl input arguments [PATCH]  (Alex Hunsaker <badalex@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Extensions versus pg_upgrade
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Extensions versus pg_upgrade