Are you speaking of the ResultSet returned from a search?
If so, what is the business use case that this needs to be trimmed. You should be able to just ignore the data you do not need.
One use case for a reduced result set would be in the case of trying to return a large number of results (or rows) and there are lots of fields (or columns) in the dataset. Reducing the number of columns would allow for more rows of data to fit into server memory before going OOM. I've seen this case before, but this case is really a combination of trying to return too many results in conjunction with having a metadata model with too many fields.
Back to Jonathan's point, though, you could just ignore the extra columns during the processing if the result set. If you really need to return fewer columns, you need a customization that returns the distinct columns that are desired. To enforce security, I'd suggest looking at creating a datasource instead of a standard SQL query. The datasource, if built correctly, already does the security calculations so there's no need to jump through extra hoops to filter the result set. Look in the HowTo components (I think it's the data access component) for an example of how to create a datasource.
I'm not sure this explanation is really the use case that Jonathan was looking for.
In any event, Jiri already answered the profile question in your other post. Profiles just don't work that way.
I'm curious though, why do you have to "iterate and ignore" fields? There is going to be a result set in the binder, and a field can be directly referenced by name (e.g. "SearchResults.xComments"). There's really no need for the iteration, since you already know the fields you want out of the result set. Otherwise, you couldn't possibly define the fields to exclude in a profile (if that approach.was even possible).
Perhaps if you could explain the business case (and not the technical aspects) of the problem you are trying to solve it would help.
if you really need to do this than it can be done at 2 places depending on your requirement.
1. If this trimming is only required for your application where your are using RIDC then you can write a wrapper over RIDC search API that will trim the search results. Expose that wrapper API to every party who are interest in getting trimmed search results. That way change will be centralized at one location and will be easy to maintain.
2. If it has to be done globally than you can either modify GET_SEARCH_RESULTS service to add a new custom java as last action of service that will trim the SearchResults result set returned by getSearchResults action. You can even use a custom variable to check if you need to return non trimmed results or trimmed results. pass that variable to your RIDC search call and in your custom action check for that variable. If that varialbe is true then provide trimmed result set otherwise do not do anything in your custom action and let go everything as it is.