Uważam, że WSZYSTKIE i WSZYSTKIE są bardzo przydatne, gdy nie tylko testujesz równość lub nierówność. Rozważ
'blah' LIKE ANY (ARRAY['%lah', '%fah', '%dah']);
jak użyłem mojej odpowiedzi na to pytanie .
ANY , ALL a ich negacje mogą znacznie uprościć kod, który w przeciwnym razie wymagałby nietrywialnych podzapytań lub CTE, a moim zdaniem są one znacznie niedostatecznie wykorzystywane.
Weź pod uwagę, że ANY będzie współpracować z każdym operatorem. Jest to bardzo przydatne z LIKE i ~ , ale będzie działać z tsquery, testami członkostwa w tablicy, testami kluczy hstore i innymi.
'a => 1, e => 2'::hstore ? ANY (ARRAY['a', 'b', 'c', 'd'])
lub:
'a => 1, b => 2'::hstore ? ALL (ARRAY['a', 'b'])
Bez ANY lub ALL prawdopodobnie będziesz musiał wyrazić je jako podzapytanie lub CTE przez VALUES lista z agregatem, aby uzyskać pojedynczy wynik. Jasne, możesz to zrobić, jeśli chcesz, ale pozostanę przy ANY .
Jest jedno prawdziwe zastrzeżenie:w starszych wersjach Pg, jeśli piszesz ANY( SELECT ... ) , prawie na pewno poprawi się wydajność dzięki EXISTS (SELECT 1 FROM ... WHERE ...) . Jeśli korzystasz z wersji, w której optymalizator włączy ANY (...) do przyłączenia, to nie musisz się martwić. W razie wątpliwości sprawdź EXPLAIN wyjście.
