On Fri, Aug 12, 2011 at 18:00, David E. Wheeler <david@kineticode.com> wrote:
> Hackers,
>
> Given this script on 9.1beta3:
>
> BEGIN;
>
> CREATE EXTENSION plperl;
>
> CREATE OR REPLACE FUNCTION wtf(
> ) RETURNS TEXT[] LANGUAGE plperl AS $$ return []; $$;
>
> SELECT wtf() = '{}'::TEXT[];
> Why is that? If I save the values to TEXT[] columns, they are still not the same. But if I pg_dump them and then load
themup again, they *are* the same. The dump looks like this:
Eek.
> Is PL/Perl doing something funky under the hood to array values it returns on 9.1?
Yeah, its not handling empty arrays very well (its calling
accumArrayResult which increments the number of elements even when we
are a zero length array).
This was rewritten in 9.1 as part of the array overhaul. Previously
returned arrays were converted into a string with the perl sub
encode_array_literal(), potgres would then convert that string into
the appropriate data type. Not only was that a tad inefficient, but it
failed to handle composite types nicely. In 9.1 you can pass in arrays
with composite types and the like, we figured it would be awfully nice
if you could return them as well :-)
Anyway, the attached patch fixes it for me. That is when we don't have
an array state, just return an empty array. (Also adds some
additional comments)
I thought about doing this right after we set dims[0] in
plperl_array_to_datum(), but that would fail to handle nested empty
multidim arrays like [[]]. As long as you can do that via
ARRAY[ARRAY[]]... I figure plperl should support it to.
Thanks for the report!