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
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
