Re: plperl better array support
От | Andrew Dunstan |
---|---|
Тема | Re: plperl better array support |
Дата | |
Msg-id | 42B9C0F4.4010103@dunslane.net обсуждение исходный текст |
Ответ на | plperl better array support (Andrew Dunstan <andrew@dunslane.net>) |
Список | pgsql-patches |
I wrote: > > The attached patch (submitted for comment) is somewhat adapted from > one submitted last October. This allows returning a perl array where a > postgres array is expected. > > example: > > andrew=# create function blurfl() returns text[] language plperl as $$ > andrew$# return ['a','b','c','a"b\c']; > andrew$# $$; > CREATE FUNCTION > andrew=# select blurfl(); > blurfl ------------------- > {a,b,c,"a\"b\\c"} > > > Unlike the patch from October, this patch does not implement ANYARRAY > or ANYELEMENT pseudotypes. However it does escape/quote array elements > where necessary. It also preserves the old behaviour (if the plperl > function returns a string it is just passed through). > > I'm not happy about constructing a string which we then parse out > again into an array - that strikes me as quite inefficient. (And there > are other inelegancies that I'd like to get rid of.) Much better would > be to use some array contruction calls directly - any pointers on how > to do that would be apprciated :-) > [snip] I have been wondering whether a better approach might be to provide a builtin plperl function that would construct the array string for us. The downside is that the plperl programmer would have to be aware of it. The upside would be that it would probably be faster (no massive calling from C->perl) and it would take better account of things like binary nulls, which we might otherwise barf on. They aren't mutually exclusive - we could implement what I originally intended later on if we go with this approach. thoughts? cheers andrew
В списке pgsql-patches по дате отправления: