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
