1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
[]
= "cratestack-sqlx"
= true
= true
= true
= true
= true
= true
= true
= true
= true
= "README.md"
= true
= true
[]
= true
[]
# cratestack#505 Direction 2: no longer mutually exclusive — both may be
# selected in the same build. `query/support/values.rs`'s `bind_decimal`
# downcasts `SqlValue::Decimal`'s boxed payload to whichever concrete
# type(s) these features enabled at runtime, so both backends' `dep:`/
# `sqlx-core`/`sqlx-postgres` forwards below may be active simultaneously
# with no conflict — each just adds an `Encode`/`Type` impl this crate can
# choose to use, it doesn't have to be the *only* one.
= ["decimal-rust-decimal"]
= [
"cratestack-core/decimal-rust-decimal",
"cratestack-sql/decimal-rust-decimal",
"cratestack-policy/decimal-rust-decimal",
"dep:rust_decimal",
"sqlx-core/rust_decimal",
"sqlx-postgres/rust_decimal",
]
# Mirrors `decimal-rust-decimal` above for the `bigdecimal` backend
# (cratestack#495). `sqlx-core`/`sqlx-postgres` 0.8.6 both declare
# `bigdecimal` as a plain optional dependency (no explicit `[features]`
# entry for it, same as `rust_decimal` above) — Cargo auto-generates the
# matching implicit feature for any optional dependency declared without
# `dep:` syntax, which is what `sqlx-core/bigdecimal` /
# `sqlx-postgres/bigdecimal` below select. This is what gives
# `bigdecimal::BigDecimal` real `sqlx::Type`/`Encode`/`Decode` impls
# against Postgres's `NUMERIC` wire format.
= [
"cratestack-core/decimal-bigdecimal",
"cratestack-sql/decimal-bigdecimal",
"cratestack-policy/decimal-bigdecimal",
"dep:bigdecimal",
"sqlx-core/bigdecimal",
"sqlx-postgres/bigdecimal",
]
# Column-type support for `Vector(n)` fields (the `pgvector` extension
# — see `docs/design/extensions.md` §6). Pulls in the `pgvector` crate
# purely for its `sqlx::Type`/`Encode`/`Decode` impls against
# Postgres's `vector` wire format — reinventing that binary encoding
# by hand isn't worth it. `default-features = false` + only the
# `sqlx` feature keeps this from pulling `sqlx-sqlite` (which would
# reintroduce the exact `libsqlite3-sys` conflict with `rusqlite` that
# the `sqlx` compatibility shim above exists to avoid): the `pgvector`
# crate's own `sqlx` feature depends on the umbrella `sqlx` crate with
# `default-features = false, features = ["postgres"]` only, so
# `sqlx-sqlite` never enters the resolved graph.
= ["dep:pgvector", "dep:sqlx"]
[]
= true
= true
= true
= true
= true
= true
= true
= true
= true
= true
= true
= true
= true
= { = true, = true }
= { = true, = true }
= { = true, = true }
# Pins the transitive `sqlx` facade crate pgvector's `sqlx` feature
# pulls in to exactly the version whose `sqlx-core`/`sqlx-postgres`
# match our own direct `=0.8.6` pins above. Without this, pgvector's
# own (loose) `>= 0.8, < 0.10` requirement lets Cargo resolve a
# separate, newer `sqlx-core`/`sqlx-postgres` (e.g. 0.9.x) alongside
# our pinned 0.8.6 ones, and `pgvector::Vector`'s `Encode`/`Type` impls
# (written against the newer copy) then fail to satisfy
# `QueryBuilder::push_bind`'s bound (written against ours) — not a
# missing impl, just two incompatible copies of the same trait. Not
# used directly (we still go through the `sqlx-core`/`sqlx-postgres`
# shim above), this dependency exists purely to anchor the resolver.
= { = "=0.8.6", = false, = ["postgres"], = true }
[]