Possible bug (or at least unexpected behavior) - Mailing list pgsql-sql

From Adam Mackler
Subject Possible bug (or at least unexpected behavior)
Date
Msg-id WScDU5qfoZ7PB2gXwNqwGGgDPmWzz08VdydcPFLhOwUKZcdWbblbo-0Lku-qhuEiZoXJ82jpiQU4hOjOcrevYEDeoAvz6nR0IU4IHhXnaCA=@mackler.email
Whole thread Raw
Responses Re: Possible bug (or at least unexpected behavior)  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-sql
Hi, forgive me if I should be posting this somewhere else.  I asked the following question on stackoverflow, and the
firstresponse suggests a possible bug: 


https://stackoverflow.com/questions/73261240/recursive-sql-function-returning-array-has-extra-elements-when-self-invocation-u#73261240

Briefly, given the following function:

    CREATE FUNCTION runs(input int[], output int[] DEFAULT '{}')
    RETURNS int[] AS $$
      SELECT
        CASE WHEN cardinality(input) = 0 THEN output
        ELSE runs(input[2:],
                  array_append(output, CASE
                    WHEN input[1] = 0 THEN 0
                    ELSE output[cardinality(output)] + input[1]
                  END)
                 )
        END
    $$ LANGUAGE SQL;

I expect the following invocation to return an array with the same number of elements as the passed-in argument array:

    # select runs('{0,1,1,1,1,0,-1,-1,-1,0}');
                      runs
    ----------------------------------------
     {0,1,2,3,4,5,6,0,0,0,-1,-2,-3,-4,-5,0}
    (1 row)

which it does not with PostgreSQL version 14.4.  If it not a bug, then I would be extremely interested in why it's
returningan array with more elements than the input array has. 

Thanks in advance,
--
Adam Mackler




pgsql-sql by date:

Previous
From: Karsten Hilbert
Date:
Subject: Re: JDBC Driver for postgres 9.6
Next
From: Tom Lane
Date:
Subject: Re: Possible bug (or at least unexpected behavior)