Just to clarify Sachin's post....
You can do this (multi-select in the filter) easily for "normal" fields - i.e. attributes you also RETURN in the query.
But you CAN'T do this for the custom/non-returned parameter fields (the ones that appear as "param_" attributes).
(simple workaround might be to provide a couple of "param_" attributes and write the OR clause yourself in the NSQL - not very elegant and is functionally restricted, but it will work)
--
And a little word of warning arounf mulit-select filters though (and this might be a little deep and might not be an issue for you!) - Whilst you can usually "Preview" the SQL in the NSQL editor window (so you can get an idea of what is really going on), this WILL NOT tell you how the SQL is generated for a multi-select filter parameter (since you only define the "multi-valued"ness of the field in the portlet definition not the query defintion)*. In practice the SQL gets produced with a big "OR clause" with hard-coded values (coded to the ones the user selects at run-time). On Oracle systems this is actually a very INEFFICIENT technique since a new query is produced ever time it is run (with different parameters) - and so the (usually very efficient) Oracle query-execution-path-caching stuff that goes on can not be used. Furthermore, a long list of OR fields might (and I stress "might") cause your generated SQL itself to be pretty inefficient (of course there are many factors that "might" cause the SQL to inefficient, its just that in this case its a bit less obvious since you are not so much in control of the generated SQL)
*The only way you can see EXACTLY what is going on at SQL level is to look at the SQL as it executes on the database
(phew!)
B)