Decomposer / Composer interface; driver support

[Daniel Theophanes]

Go SQL driver maintainers:

When the decomposer interface was added (though not yet publicly declared), I was designed to gracefully grow into it. https://github.com/golang-sql/decomposer

I failed to take into account one scenario:

Should a decimal type directly implement a driver.Valuer interface (like shopspring) or should it be embedded into a decimal type that satisfies a Valuer interface (like sqlboiler does), the driver.DefaultParameterConverter will recognize the value as a valid value because IsValid was modified to recognize the decomposer value.

This combination breaks existing implementations when the sql driver doesn't recognize the decomposer interface.

I can either try to rollback the decomposer experiment, either partially or fully, or we can recognize the decomposer type as a fundamental type that may get passed to the driver. I would prefer to update database drivers to support the decomposer interface, because I see this as the best way forward to support decimals generally.

What would your preference be and why?

Thank you, -Daniel

[Tamás Gulácsi]

I'm open for adding such interface into my driver (godror/godor, for Oracle).

Oracle's NUMBER type can store 38 decimal digits with exponent between -130 and 125, which is quite a stretch for int64.

Now I transfer this as string, which is safe but slow.

The Oracle C driver's developer (Anthony Tuininga) is open for exposing the underlying 22 bytes of OCINumber, and that could be composed/decomposed with little effort.