Hi Tom, > ANY(SELECT ...) normally means searching down the rows ah, yeah, but I was focussing here more on the ANY(<array>) from documentation paragraph 9.21.3 (postgresql v9.1.1): expression operator ANY (array expression) > where the select is expected to return a single column matching the type > of the LHS I understand. Here though, I was in a situation where I knew the select would return a single row with a single array typed column > You stuck a cast in there, which satisfies the syntactic restriction, > but realize that you've broken the ability to search multiple rows of > the select result. clear, which in a way matched what I was trying to achieve So, basically, an ANY(...) construct will favor the ANY(SELECT...) over the ANY(<array>) by maintaining the notion of getting a set of rows from the inner expression, even when written as ANY((SELECT...))? Seems to make sense ;) > In the particular example here, SELECT is just a waste of typing. > But I assume it's a dumbed-down example. oh, definitely, but you nailed it already in your next remark: > Depending on what you're really doing, it might be sensible to use > ANY(SELECT UNNEST(arrayvalue) FROM ...) if you're trying to search > through elements of a column of array values. right, 'unnest'..... see, I'm not using array's enough, this got added yesterday, right ? ;) Thanks for you response! -- Best, Frank. -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
