Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
GitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
database/sql: different handling of underlying types in DefaultParameterConverter #15174
// DefaultParameterConverter returns its argument directly if
Underlying integers are really converted to int64, but underlying strings are not in fact converted – there is no code for this.
I propose to do what documentation says and convert the underlying string to byte, it will help with custom string-like types with constants (enums).
@220kts The change I had in mind here is quite straightforward,
Thanks @sctb The current implementation is a bit inconsistent in its handling of nil pointers: a nil pointer to a basic type returns
I would suggest to handle nil pointers consistently between basic types and types that implement the Valuer interface. In the case of a type that implements the Valuer interface, this would allow the caller to decide whether to pass a pointer or a value to the ConvertValue function (which logically tends to correspond to database columns with or without NOT NULL constraint).
Just thought it might make sense to consider that along with the change you propose.
It wasn't my intention to limit this issue only to query parameters, although my analysis was incorrect. Basically, I wanted to be able to insert a value into a database and read it back into the same variable. And I wanted this behavior to be consistent for both predeclared types and named types with predeclared underlying types. As testcase shows, I can do it for
The reason why my analysis was incorrect is this comment:
I will create a new issue.