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.


andrew=# create function blurfl() returns text[] language plperl as $$
andrew$# return ['a','b','c','a"b\c'];
andrew$# $$;
andrew=# select blurfl();
     blurfl      -------------------

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 :-)


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.




---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Reply via email to