!= ANY(array) does not behave as expected

[Chris Wilson <chris.wilson@xxxxxxxxxxxxxxxxx>]

Dear Postgres users,

 

I like using ANY(array) instead of IN (…), as we can pass the array as binary data, avoiding the need to render its contents (which might be integers) into a SQL string, for Postgres to parse them back into integers again, and it also works with an empty list. For example:

 

create table foo (id integer);

insert into foo (id) values (1), (2), (3);

select * from foo where id IN (1, 2); /* returns rows 1 and 2 */

select * from foo where id = ANY (ARRAY[1, 2]); /* returns rows 1 and 2 */

 

However, if we try to invert it by using the != operator, then we get unexpected results:

 

select * from foo where id NOT IN (1, 2); /* returns row 3 only, as expected */

select * from foo where id != ANY (ARRAY[1, 2]); /* returns all rows, unexpected */

 

I don’t really understand why this is the case. I guess that perhaps an ANY-object has an equality operator that tests for membership of the array, but its inequality operator does something different. I don’t understand what it’s doing at all, or how it might be useful. Could anyone enlighten me?

 

I did find a workaround that may be useful to others (perhaps something to add to the documentation?):

 

select * from foo where NOT(id = ANY (ARRAY[1, 2])); /* returns row 3 only, as expected */

 

In a search for a solution or workaround, to pass arrays of IDs to exclude into queries, I noted that the manual says:

 

_expression_ NOT IN (subquery)

The right-hand side is a parenthesized subquery, which must return exactly one column.

I tried to pass an _expression_ that returns one column, but that failed:

 

select * from foo where id NOT IN (unnest(ARRAY[1, 2])); /* fails with “set-returning functions are not allowed in WHERE” */

 

But if I use a real subquery then it succeeds:

 

select * from foo where id NOT IN (SELECT * FROM unnest(ARRAY[1, 2])) /* returns row 3 only */

 

If the current behaviour of != ANY (ARRAY…) is not useful, then is there any support for (or opposition to) fixing it? And is it a bug that one can’t use unnest in a NOT IN _expression_ in the WHERE clause?

 

Thanks, Chris.