launchbadge
Ability to use `sqlx` without `serde` (and potentially `syn`)
I have found these related issues/pull requests
No directly related issues.
Description
Currently, sqlx always depends on serde.
It's pulled in mainly through the "offline" sqlx-core capability, which is not exposed as a feature at the sqlx level.
For sqlx-postgres, it's also used to handle parsing JSON query plans, in order to mark columns as nullable.
If serde was to becomes optional, it would then be relatively simple to make a syn free build too.
The only additional changes needed would be removing use of thiserror, and disabling the "attributes" tracing feature (which is unused anyways).
From my quick proof of concept, this would result in the compile time of a minimal build of sqlx (runtime-smol,postgres,migrate) dropping from 21s to 16s.
Prefered solution
Expose "offline" as a feature (enabled by default) for sqlx, allowing for it to be disabled.
Move the nullable columns logic in sqlx-postgres to the DB instead, removing the need to parse any query plans on the library side.
Only depend on serde through relevant features. (offline, json, ...)
And optionally remove use of thiserror, tracing/attributes.
Is this a breaking change? Why or why not?
Yes, this would be a breaking change, due to moving "offline" to be a sqlx feature again.
Here's the --timings files for the before and after syn builds:
Move the nullable columns logic in sqlx-postgres to the DB instead, removing the need to parse any query plans on the library side.
This pessimizes every single query macro invocation by adding an extra round-trip to the database, making it a non-starter.
However, Describe is not a public API; it only exists to support the query macros. If you're trying to eliminate syn from your build, then you're not using the query macros anyways. So instead of re-exposing the offline feature, why don't we just tie it to the macros feature? If you disable the macros feature, the EXPLAIN parsing can just go away entirely.
However, Describe is not a public API; it only exists to support the query macros.
Ah, I overlooked that aspect. Yes, that would be a much nicer solution.