Why complex FRN queries stay manual review
Complex FRN-style queries are a good example of why database support needs nuance. The product may understand the source pattern and even classify it by provider family, but that does not automatically mean a safe 1:1 native action exists for export.
What makes these queries different
Complex database workflows often use joins, counts, sums, CASE expressions, vendor-specific functions such as RRN, or hand-built logic that spans several tables. Those are not the same as a clean get-row or get-rows connector action.
Even if the database family is recognized correctly, the native connector may not expose an equivalent arbitrary-query shape that is safe to emit generically.
Why a placeholder can still be the honest answer
A placeholder or partial classification is not a failure if it prevents the product from pretending a complex query was safely converted when it was not. That gives teams a truthful migration plan: native where possible, manual review where the business logic is too custom or too query-heavy to trust automatically.
For portfolio planning, that honesty is more useful than inflating the supported count.
How to use that information
If the workflow has only one or two complex queries surrounded by otherwise standard logic, it can still be a strong migration candidate. Treat the query steps as manual islands inside a largely convertible process rather than throwing the whole workflow away.
The right question is not 'is every step native'. The right question is 'where should engineering time go'.