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 real fast. > > 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.
pg_to_perl_arrays_v8.patch.gz
Description: GNU Zip compressed data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers