Re: arrays as pl/perl input arguments [PATCH]
От | Alexey Klyukin |
---|---|
Тема | Re: arrays as pl/perl input arguments [PATCH] |
Дата | |
Msg-id | 906E6724-A4E2-4A34-AD7F-F4437EE19D5A@commandprompt.com обсуждение исходный текст |
Ответ на | Re: arrays as pl/perl input arguments [PATCH] (Alex Hunsaker <badalex@gmail.com>) |
Ответы |
Re: arrays as pl/perl input arguments [PATCH]
|
Список | pgsql-hackers |
Hi, On Jan 26, 2011, at 8:45 PM, Alex Hunsaker wrote: > On Sat, Jan 15, 2011 at 15:48, Alex Hunsaker <badalex@gmail.com> wrote: >> On Wed, Jan 12, 2011 at 13:04, Alexey Klyukin <alexk@commandprompt.com> wrote: >>> >>> On Jan 12, 2011, at 8:52 PM, David E. Wheeler wrote: >>> >>>> On Jan 12, 2011, at 5:14 AM, Alexey Klyukin wrote: >>>> >>>>> You mean packing both a string representation and a reference to a single SV * value? >>>> >>>> Dunno, I'm not a guts guy. >>> >>> Well, neither me (I haven't used much of the guts api there). >> >> Find attached a proof of concept that modifies Alexey's patch to do >> the above (using the overload example I and others posted). > [ ... ] >> Thoughts? Should I polish this a bit more? Or do we like the GUC better? > > So its been over a week with no comments. ISTM there were more people > against adding yet another GUC. Barring objection ill finish the > missing parts of the POC patch I posted and submit that. I've played with that patch just today. I found a problem with it, when I tried to use the array in a string context thebackend segfaulted with: "WARNING: Deep recursion on subroutine "main::encode_array_literal" at -e line 74" just beforethe segfault. I think the problem is in the regexp check in 'encode_array_literal' (it's obviously reversed comparingwith the original one), but it still segfaults after I fixed that. Other than that, the approach looks good to me, I'm for eliminating the GUC setting in favor of it. /A -- Alexey Klyukin The PostgreSQL Company - Command Prompt, Inc.
В списке pgsql-hackers по дате отправления: