Expose executor via InternalExecutorBundle on Client #494
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This adds an
InternalExecutorBundle()
method toClient
which returns a newdriver.InternalExecutorBundle[TTx]
interface type. The interface exposes the driver's internal executors viaExecutor()
andExecutorTx(tx)
methods. This can enable external modules to run queries against River's underlying drivers, including arbitrary SQL.Compatibility interfaces for
ExecResult
,Rows
, andRow
are able to paper over the basic differences betweendatabase/sql
andpgx
in order to expose just enough functionality for basic arbitrary SQL queries.For now, this allows us to run simple SQL queries against River's drivers from external libraries. In the future, it could be a path toward extracting most of the duplicate queries in drivers into a shared query module that isn't driver-specific. Drivers would become a simpler interface focused on
Exec
/Query
/QueryRow
and row scanning details, rather than each needing to implement every query under the sun.A final commit ef5dff2 demonstrates a possible extension of this pattern to expand the driver interface so that it can abstract all details of deserializing
river_job
rows, allowing driver-specific details like[]byte
vsstring
for json to be tucked away in a single implementation, even if external packages are able to run arbitrary queries for jobs. This commit can be omitted from merge but I wanted to at least illustrate the potential here.