I don't know if this makes sense as a stand alone issue. There is currently no decision that is based upon the order of the access patterns.
My case is that table T that models an API. The API has three forms:
To ensure the planner pushes down appropriate parameters, I would want to create two access patterns but since I have no explicit control over which access pattern the planner chooses, I cannot guarantee that the planner will push qualifers for a and b if the client supplies both.
This goes back to the problem referenced in Feature request - depjoin-like functionality for stored procedures it's really about trying to create parameterized view-like functionality
This starts to get into a pretty grey area. If you specify predicates against a and b, and they can be pushed, then under most circumstances we will use both - this isn't expressly guaranteed, but we don't currently have a situation where this wouldn't be true.
If there is an access pattern specifying both, then that will be required. The questions are what does it mean to be missing the b predicate, and what does it mean to have a b predicate that cannot be pushed (usage of a function, unsupported comparison, etc.) In the former case it's pretty clear that your intent is that the source access should still be allowed since there would be an alternative access pattern. However the latter case is not clear. Do you intend for the access to still happen only using a or is it a usage error? Are you allowing for b values to be projected - select a, b... from T where a = x and b = y?
Thinking out loud... If the api is being modeled as a table, it must follow table semantics. In this case, an api call that qualifies argument a must return a superset of the same api call that qualifies arguments a and b. At best, SELECT * FROM (api(1, 2)) is a performance optimization on SELECT * FROM (api(a)) WHERE api.b=2. So, if there are two access patterns, one specifying a and another specifying a & b, not pushing b should still allow access.
Following the same logic, select a,b from T where a = x and b = y had better yield either an empty result set or a single row of x, y.
Now, the question is, how applicable is the underlying assumption that apis should be modeled as a table. Obviously, in the general case, there's no reason why api(a,b) should return a subset of api(a). From that perspective, it's much better to model the api as a stored procedure. This wouldn't be a problem except that it becomes difficult - or impossible - to apply a performance optimization for batches. This gets us right back to the other feature request.
Ultimately, for this particular request, I don't think it's worth it.
Ok, let's focus on the other one for now.