Consider the following dummy table (this is a simplified example from a bigger query):
create table sample_data (id int, id_list int[]);
insert into sample_data (id, id_list)
values
(1, array[1,2,3]),
(2, array[2,3,4]),
(3, array[4,5,6]);
The following statement tries to find the overlapping values in id_list between the current row and the next row:
select id,
id_list,
lead(id_list) over (order by id) as next_list,
array(select unnest(id_list) intersect select unnest(lead(id_list) over (order by id))) as common_ids
from sample_data;
The above returns:
id | id_list | next_list | common_ids
---+---------+-----------+-----------
1 | {1,2,3} | {2,3,4} | {}
2 | {2,3,4} | {4,5,6} | {}
3 | {4,5,6} | | {}
The empty array for "common_ids" is obviously incorrect.
However, when the evaluation of the "next_list" is put into a derived table, then this works as expected:
select id, id_list, next_list,
array(select unnest(id_list) intersect select unnest(next_list)) as common_ids
from (
select id,
id_list,
lead(id_list) over (order by id) as next_list
from sample_data
) t
returns:
id | id_list | next_list | common_ids
---+---------+-----------+-----------
1 | {1,2,3} | {2,3,4} | {2,3}
2 | {2,3,4} | {4,5,6} | {4}
3 | {4,5,6} | | {}
This is with Postgres 11.4
Is this a bug or simply not supported?
It does work correctly with intarray's "intersect" operator:
select id,
id_list,
id_list & lead(id_list) over (order by id) as next_list
from sample_data;
However, the actual data uses a bigint, so intarray isn't an option.
Thomas