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[];

ROLLBACK;

The output is:

BEGIN
CREATE EXTENSION
CREATE FUNCTION
?column?
----------
f
(1 row)

ROLLBACK

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 them up again, they *are* the same. The dump looks like this:

CREATE TABLE gtf (
have text[],
want text[]
);

COPY gtf (have, want) FROM stdin;
{} {}
\.


Is PL/Perl doing something funky under the hood to array values it returns on 9.1?

Thanks,

David

Search Discussions

  • Alex Hunsaker at Aug 13, 2011 at 1:17 am

    On Fri, Aug 12, 2011 at 18:00, David E. Wheeler 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 them up 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!
  • David E. Wheeler at Aug 13, 2011 at 2:49 am

    On Aug 12, 2011, at 6:17 PM, Alex Hunsaker wrote:

    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)
    Fix confirmed, thank you!

    +1 to getting this committed before the next beta/RC.

    David
  • Darren Duncan at Aug 13, 2011 at 3:09 am

    David E. Wheeler wrote:
    On Aug 12, 2011, at 6:17 PM, Alex Hunsaker wrote:
    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)
    Fix confirmed, thank you!

    +1 to getting this committed before the next beta/RC.
    Policy question. If this problem hadn't been detected until after 9.1 was
    declared production, would it have been considered a bug to fix in 9.1.x or
    would it have been delayed to 9.2 since that fix might be considered an
    incompatibility? If the latter, then I'm really glad it was found now. --
    Darren Duncan
  • Peter Eisentraut at Aug 13, 2011 at 8:15 am

    On fre, 2011-08-12 at 20:09 -0700, Darren Duncan wrote:
    David E. Wheeler wrote:
    On Aug 12, 2011, at 6:17 PM, Alex Hunsaker wrote:
    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)
    Fix confirmed, thank you!

    +1 to getting this committed before the next beta/RC.
    Policy question. If this problem hadn't been detected until after 9.1 was
    declared production, would it have been considered a bug to fix in 9.1.x or
    would it have been delayed to 9.2 since that fix might be considered an
    incompatibility?
    Surely this would be a bug fix.
  • Andrew Dunstan at Aug 17, 2011 at 4:06 pm
    On 08/12/2011 09:17 PM, Alex Hunsaker wrote:

    [empty arrays returned are not handled correctly]
    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)
    Applied, thanks.

    cheers

    andrew
  • David E. Wheeler at Aug 17, 2011 at 5:32 pm

    On Aug 17, 2011, at 9:06 AM, Andrew Dunstan wrote:

    [empty arrays returned are not handled correctly]
    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)
    Applied, thanks.
    Awesome, thanks!

    David
  • Alex Hunsaker at Aug 17, 2011 at 8:29 pm

    On Wed, Aug 17, 2011 at 10:06, Andrew Dunstan wrote:

    On 08/12/2011 09:17 PM, Alex Hunsaker wrote:

    [empty arrays returned are not handled correctly]
    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)
    Applied, thanks.
    Thanks for picking this up.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppgsql-hackers @
categoriespostgresql
postedAug 13, '11 at 12:00a
activeAug 17, '11 at 8:29p
posts8
users5
websitepostgresql.org...
irc#postgresql

People

Translate

site design / logo © 2021 Grokbase