In FEDERATE-126 more granular connector capabilities were requested, for supporting sources that don't follow traditional relational capability patterns (especially SFDC).

The level of effort for such a request is presumably fairly high for the DQP component, since it needs to have additional logic added to understand the new capability and to modify the planning process to take them into account.

It occurred to me that a general purpose backup mechanism would be for connectors to have the ability after getting a query they couldn't handle, to throw a new type of exception (perhaps ReplanRequestException), which would contain information about what connector capabilities should be excluded from the replanning process. Then the planner would come up with a new plan, and make new source query/queries based off that new plan.

For example take the case of SFDC, which handles outer joins (left or right, but not full) but not inner joins (and for the sake of argument say that FEDERATE-126 and FEDERATE-114 were not implemented). The SFDC connector gets sent a query with an inner join. It then throws an exception requesting a replan, this time with no join pushdown. Then the planner replans this as without join pushdown, and resubmits the query (or in many cases multiple queries).

Now, one big question here is, does replanning mean replanning the entire federated query, or just redoing that one source query? The former would give a more efficient overall plan, but it may be too late to do this (other connectors may already be at work). For the former to work, I would think we would need to have an additional step in the connector framework to run the proposed query plan by all the connectors before actually executing anything, which would be additional overhead on all queries, not the small subset for which this problem exists. So maybe the latter (redoing that one source query) is the only reasonable alternative.

A workaround with similar results is FEDERATE-114 style stuff (tell the consumer what was wrong, and ask them to override connector capabilities in a new query. But that has the same general inefficiency of an automatic replanning of the entire federated query. So it would not be as nice as replanning just one source query.