Ich finde ANY und ALL sehr nützlich, wenn Sie nicht nur Gleichheit oder Ungleichheit testen. Betrachten Sie
'blah' LIKE ANY (ARRAY['%lah', '%fah', '%dah']);
wie meine Antwort auf diese Frage verwendet .
ANY , ALL und ihre Negationen können Code erheblich vereinfachen, der sonst nicht-triviale Unterabfragen oder CTEs erfordern würde, und meiner Ansicht nach werden sie erheblich zu wenig genutzt.
Beachten Sie, dass ANY funktioniert mit jedem Operator. Es ist sehr praktisch mit LIKE und ~ , funktioniert aber mit tsquery, Array-Mitgliedschaftstests, hstore-Schlüsseltests und mehr.
'a => 1, e => 2'::hstore ? ANY (ARRAY['a', 'b', 'c', 'd'])
oder:
'a => 1, b => 2'::hstore ? ALL (ARRAY['a', 'b'])
Ohne ANY oder ALL Sie müssten diese wahrscheinlich als Unterabfrage oder CTE über VALUES ausdrücken Liste mit einem Aggregat, um ein einzelnes Ergebnis zu erzeugen. Natürlich können Sie das tun, wenn Sie möchten, aber ich bleibe bei ANY .
Hier gibt es eine echte Einschränkung:Bei älteren Pg-Versionen, wenn Sie ANY( SELECT ... ) schreiben , sind Sie mit EXISTS (SELECT 1 FROM ... WHERE ...) ziemlich sicher leistungsmäßig besser dran . Wenn Sie eine Version verwenden, bei der der Optimierer ANY (...) ändert in einen Join, dann brauchen Sie sich keine Sorgen zu machen. Überprüfen Sie im Zweifelsfall EXPLAIN Ausgabe.
