Query.returning is currently required, because the library needs it to turn a query (from a query factory or the built-in makeQuery logic) into a Result.
However, custom queries constructed within a result factory (i.e., that get passed to opts.runQuery), for which the QueryReturning data is just used as an intermediate value to construct some larger result, really don't need a query.returning. So, make that optional, and use an intersection/mapped type to make it required (only) in the places we actually need it.
Somewhat unrelated, would ResourceWithId et al and instead having Resource<T extends string | undefined = string | undefined> add anything? I don't think so at the moment.
Query.returningis currently required, because the library needs it to turn a query (from a query factory or the built-inmakeQuerylogic) into a Result.However, custom queries constructed within a result factory (i.e., that get passed to
opts.runQuery), for which the QueryReturning data is just used as an intermediate value to construct some larger result, really don't need aquery.returning. So, make that optional, and use an intersection/mapped type to make it required (only) in the places we actually need it.Somewhat unrelated, would ResourceWithId et al and instead having
Resource<T extends string | undefined = string | undefined>add anything? I don't think so at the moment.