On Feb 10, 2011, at 11:26 PM, Alexey Klyukin wrote:
> On Feb 10, 2011, at 9:44 PM, Andrew Dunstan wrote:
>
>> On 02/10/2011 08:15 AM, Alexey Klyukin wrote:
>>>
>>> Let me try implementing that as an XS interface to plperl_array_to_datum.
>>
>>
>> Are you intending this as a completion of the current patch or as 9.2 work? If the former you need to send it in
realfast.
>
> I'd like to extend the current patch, going to post the update by tomorrow.
So, here is the v8. Instead of rewriting the encode_array_literal I've added
another function, encode_type_literal (could use a better name). basically a
user-level interface to plperl_sv_to_datum, which accepts the perl variable
and the type name as a text string and returns the string representation of
the input variable according to the output function of the argument type, e..g:
do $$ elog(NOTICE, encode_type_literal([[1],[2],[3]], 'int[]'));$$ language plperl;
NOTICE: {{1},{2},{3}}
I can easily convert the encode_array_literal to just call this function, but
not encode_array_constructor, since the latter needs to produce its own string
representation, different from the result of the type output function. One
option would be traversing through the SV *, duplicating the efforts of
plperl_sv_to_datum, but I actually wonder what do we need the
encode_array_constructor (and encode_array_literal) functions for ? I
guess they were useful to pass array references to SPI, but per my
understanding it's possible to use perl array references in SPI functions
directly now, so are there any other use cases for these functions, which
justify the time to spend on updating them to support arrays of composites
(and shouldn't we also provide encode_composite_literal and
encode_composite_constructor as well) ?
/A
--
Alexey Klyukin
The PostgreSQL Company - Command Prompt, Inc.
