Possible bug (or at least unexpected behavior)
Adam Mackler <adam@mackler.email>
From: Adam Mackler <adam@mackler.email>
To: "pgsql-sql@lists.postgresql.org" <pgsql-sql@lists.postgresql.org>
Date: 2022-08-07T20:06:21Z
Lists: pgsql-sql
Hi, forgive me if I should be posting this somewhere else. I asked the following question on stackoverflow, and the first response 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 returning an array with more elements than the input array has.
Thanks in advance,
--
Adam Mackler
Commits
-
Fix handling of R/W expanded datums that are passed to SQL functions.
- ad3e07c15654 15.0 landed
- 95bfadd4e83c 14.6 landed
- 71caf3c4da1c 13.9 landed
- 5b948b5c1336 12.13 landed
- 442dbd669828 11.18 landed
- 309857f9c182 16.0 landed
- 1446612c5b25 10.23 landed