On Wed, Feb 9, 2011 at 08:24, Alexey Klyukin <al...@commandprompt.com> wrote: > > What was actually broken in encode_array_literal support of composite types > (it converted perl hashes to the literal composite-type constants, expanding > nested arrays along the way) ? I think it would be a useful extension of the > existing encode_array_literal.
Yeah, It does not work because it did not take into account the order of composite columns. It always put them alphabetically by column name. To do it properly we would need to pass in a typid or a column order or something. Ideally we could expose the new plperl_array_to_datum() to plperl functions in some manner. Here is a longer perhaps more concrete example: Imagine you have a composite type with two 'columns': => create type foo as (z int, a int); => create or replace function foo_pl(foo[]) returns foo[] as $$ my $arg = shift; $$ language plperl; => select foo_pl('{(1,2), (3,4)}'); In the above $arg looks something like (ignoring the PostgreSQL::InServer::ARRAY object) [{'a'=>2, 'z'=>1}, {'a'=>4, 'z'=>3}]. When we call encode_arary_literal() we need to put it back in to composite literal form which is basically (ignoring the array) ("column_z", "column_a"). However without type information we don't know the order of the columns, as the composite is represented as a hash we get kind of stuck. The hack I did sorted the hash keys alphabetically, which worked for the regression tests as they happened to have their composite columns sorted alphabetically. But would break for this example putting $arg->[0]{a} into z and $arg->[0]{z} into a. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers