database/sql/driver: DefaultParameterConverter breaks driver expectations when decimalDecompose is implemented #34315
Labels
NeedsInvestigation
Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone
What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (
go env
)?go env
OutputWhat did you do?
Provided a
"github.com/shopspring/decimal".Decimal
as a query parameter, using thegithub.com/lib/pq
driver.You'll need a PostgreSQL server running somewhere so that
sql.Open
can do its thing and get to the problematic point. I'm running a 10.10 server locally, but it shouldn't matter, so long as it's able to be connected to.What did you expect to see?
What did you see instead?
This seems to happen because due to the intersection of a few different behaviours:
1.13
introducing thedriver.decimalDecompose
interface as part of https://golang.org/issue/30870driver.decimalDecompose
in decimal: add decomposer interface shopspring/decimal#141IsValue()
typesThis comment in
driver.defaultConverter.ConvertValue()
seems to suggest that if a type implementsValuer
(which"github.com/shopspring/decimal".Decimal
does), then that implementation should be used overdecimalDecompose
. However,IsValue
, which has a positive match fordecimalDecompose
, is checked prior to this, and early exits without any conversion. If I remove the case fordecimalDecompose
indriver.IsValue()
, the sample program runs as expected (and as it did in Go 1.12).I'm not really sure which layer is "at fault" here, but in response to someone else raising this in in shopspring/decimal#141 (comment), @kardianos had requested that an issue be created here and that they be mentioned.
The text was updated successfully, but these errors were encountered: