On Wed, Feb 9, 2011 at 08:24, Alexey Klyukin <alexk@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.
