Extend setinputsizes() to allow specifying type+length+precision/scale

[v-chojas]

This change extends setinputsizes() in the following way: each element of the sequence passed to it can be, in addition to a single integer, a sequence of [type, length, precision/scale] to cause the specified parameter to always be bound and sent using that type. The type can be one of the pyodbc.SQL_* constants, while the length and precision/scale are integers. Any of them can be omitted or None'd to not override the corresponding value. Specifying a single integer will, as before, only override the length. E.g., the following statement:

cursor.setinputsizes([ 15, [ pyodbc.SQL_INTEGER ], None, [ None, 12, 5 ], [ pyodbc.SQL_VARCHAR, 3000 ] ])

Has the following effects:

• Column 1 will always be bound with a length of 15.
• Column 2 will always be sent with type SQL_INTEGER.
• Column 3 will not have any aspects of its type overridden.
• Column 4 will always be sent with length 12 and precision/scale 5, while its SQL type will be autodetected from the Python type.
• Column 5 will always be sent as a SQL_VARCHAR of length 3000.
• Columns 6 and above will not have any aspects of their type overridden.

Relevant issues: #260 #213

[mkleehammer]

This was an ambitious change. Thanks!

I often add to the DB API specification, but I'm a bit concerned about deviating from it too much. We should consider that.

Also, I really hate to add anything else to the parameters until they are fixed up. I completely abrogated responsibility a few months back and merged in the fast executemany with a cursory test but without going over the code. There are now two sections of code for binding parameters for each type and they do not use the same rules at all. For example, the string binding assumes every driver is using UCS2 which is absolutely not the case. Even though it is what the specification says, I spent a lot of effort writing version 4.x to add encoding support so it works with all databases.

Similarly, Decimal support was set to a string because so few databases get the binary part right the last time I tried. (Including well known ones like Oracle, IIRC.)

I started a branch to consolidate, but I was derailed by a bunch of other projects and would need to start fresh. I'm not sure the best place to have a conversation about that.

Do you see a relatively easy way to first consolidate the memory handling for binding parameters between the array and non-array versions?

[v-chojas]

Closing this since the functionality is included in the parameter array refactoring.