Restructure query arguments on custom data type with NULL value

[vitiokss]

Problem:

When we send custom go type with driver.Value interface which resolve to be nil value, the driver fails to form the right query. Driver tries still to declare the arguments with it type.

The problem self described very well in the makeDecl function:

go-mssqldb/types.go

Line 1112 in 1eb28af

case typeNull:

In our case scenario the database field is binary(16) nullable. We have custom field where driver.Value() returns nil. The query tries to declare variable as nvarchar(1) before sending it to the server

INSERT INTO test (name, binaryNilField) VALUES (@p1, @p2)
@p1 nvarchar(255), @p2 nvarchar(1) ...

, that ends up with the following error message:

mssql: Implicit conversion from data type nvarchar to binary is not allowed. Use the CONVERT function to run this query.

Solution:

Make sure we are not declaring the variables for null arguments. Instead transform query in the case that all the necessary arguments will be replaced with null value.
Same example would look like

INSERT INTO test (name, binaryNilField) VALUES (@p1, NULL)
@p1 nvarchar(255)...

[codecov]

Codecov Report

Merging #440 into master will decrease coverage by 0.11%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master     #440      +/-   ##
==========================================
- Coverage   68.64%   68.52%   -0.12%     
==========================================
  Files          22       22              
  Lines        5236     5248      +12     
==========================================
+ Hits         3594     3596       +2     
- Misses       1423     1432       +9     
- Partials      219      220       +1

Impacted Files	Coverage Δ
mssql.go	79.17% <100%> (-0.55%)	⬇️
types.go	76.99% <0%> (-0.32%)	⬇️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update ce35bd8...4c36cfa. Read the comment docs.

[kardianos]

I like the idea, I don't like the implementation. I don't want to build up the param key again just to then cause another alloc when we do a string replace for a NULL. Maybe not a big deal, but I'd rather go about it by forming the params better in the first place.