I noticed that, in the Pools tab, the search feature only allows categorizing by title, description, creator, activity status, whether it's a series or a collection, and something about sorting. This is highly limited in comparison to the usual tag system, which has thousands of categories with insight into the content of the posts in question.
Therefore, I suggest adding a seventh and eighth line to the Pool Gallery search system.

In the "Tags" line, you would be able to type a sequence of tags. How these would be handled by the system is dependent on the next line.
In the "Tag Processing" line (probably needs a better name lolz), you would choose from several options (similar to the "Status" and "Category" lines). Each option would be a different way to determine which pools get included in the search (given the other six lines are satisfied as well).

• Individual: If any of the posts in a pool match the tag sequence, the post is included in the search results. (for example, given the tag sequence "deer male", any pool that has a post with "deer" and "male" together in it would be included.) (this option would be the default, as it would interact better with syntaxes than the other options.)
• Cumulative: All the tags from the posts in the pool are combined into a single list, and if the tag sequence matches that large list, the pool is included. (for example, given the tag sequence "deer male", any pool with "deer" and "male" in it is included, even if the two tags are on different posts within the pool.)
• Omnipresent: The tag sequence has to apply to every post in the pool for it to be included. (for example, given the tag sequence "deer male", only the pools where every post within has both "deer" and "male" will be shown; all other pools, even the ones that cease to have them both for a single post, will be excluded.)

• Individual: If any of the posts in a pool match the tag sequence, the post is included in the search results. (for example, given the tag sequence "deer male", any pool that has a post with "deer" and "male" together in it would be included.) (this option would be the default, as it would interact better with syntaxes than the other options.)
• Cumulative: All the tags from the posts in the pool are combined into a single list, and if the tag sequence matches that large list, the pool is included. (for example, given the tag sequence "deer male", any pool with "deer" and "male" in it is included, even if the two tags are on different posts within the pool.)
• Omnipresent: The tag sequence has to apply to every post in the pool for it to be included. (for example, given the tag sequence "deer male", only the pools where every post within has both "deer" and "male" will be shown; all other pools, even the ones that cease to have them both for a single post, will be excluded.)

You could get results similar to your "individual" search mode by using inpool:true from the regular post search.

I don't think that the "omnipresent" or "cumulative" mode would be very useful. You would probably get too many false positives for "cumulative" mode (such as background characters or scenes only appearing once) and false negatives for "omnipresent" mode (such as with title pages that are missing tags you might be looking for).

sys-yok said:
You could get results similar to your "individual" search mode by using inpool:true from the regular post search.

I don't think that the "omnipresent" or "cumulative" mode would be very useful. You would probably get too many false positives for "cumulative" mode (such as background characters or scenes only appearing once) and false negatives for "omnipresent" mode (such as with title pages that are missing tags you might be looking for).

I was unaware of inpool:true, thank you for alerting me to that feature.

The trouble with searching 'inpool:true' is that you get a lot of entries for the same pools. And this can mean long running pools end up dominating your search. Having pools aggregate the tags from the posts in the pools and making that searchable from the pool search would be a good alternative.