On Mon, Jun 20, 2005 at 05:06:32AM -0400, Andrew Dunstan 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 :-)
Here's some pointers I'm qualified to point out, for what that's worth. ;)
In src/backend/utils/adt/arrayfuncs.c there are direct
array-manipulation functions. In the perlapi docs for perl, there are
ways to manipulate arrays directly. It should be possible to go
between perl arrays and postgresql arrays this way, except...perl
arrays can contain undef, which usually translates as NULL. Would it
be easier to add NULL support to postgresql arrays than to handle
undefs in perl arrays automagically?
Cheers,
D
--
David Fetter david@fetter.org http://fetter.org/
phone: +1 510 893 6100 mobile: +1 415 235 3778
Remember to vote!
