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.
