Je trouve que ANY et ALL sont très utiles lorsque vous ne testez pas seulement l'égalité ou l'inégalité. Considérez
'blah' LIKE ANY (ARRAY['%lah', '%fah', '%dah']);
comme utilisé ma réponse à cette question .
ANY , ALL et leurs négations peuvent grandement simplifier le code qui nécessiterait autrement des sous-requêtes ou des CTE non triviales, et elles sont considérablement sous-utilisées à mon avis.
Considérez que ANY fonctionnera avec n'importe quel opérateur. C'est très pratique avec LIKE et ~ , mais fonctionnera avec tsquery, les tests d'appartenance au tableau, les tests de clé hstore, etc.
'a => 1, e => 2'::hstore ? ANY (ARRAY['a', 'b', 'c', 'd'])
ou :
'a => 1, b => 2'::hstore ? ALL (ARRAY['a', 'b'])
Sans ANY ou ALL vous devrez probablement les exprimer sous forme de sous-requête ou de CTE sur un VALUES liste avec un agrégat pour produire un seul résultat. Bien sûr, vous pouvez le faire si vous le souhaitez, mais je m'en tiendrai à ANY .
Il y a une vraie mise en garde ici :sur les anciennes versions de Pg, si vous écrivez ANY( SELECT ... ) , vous serez presque certainement mieux loti en termes de performances avec EXISTS (SELECT 1 FROM ... WHERE ...) . Si vous êtes sur une version où l'optimiseur transformera ANY (...) dans une jointure, vous n'avez pas à vous inquiéter. En cas de doute, cochez EXPLAIN sortie.
