Removed (Number)rs.getObject(BUFFER_LENGTH) from calculation of colum…

[lelle1234]

…n length

[npetzall]

I checked the tests and saw which are failing. Only one actually or "one set". Which i MSSQL, the int column went from 10 to 4.
I looked into it, when I figured out the 10, I realized I had done the same thing previously back in #489.

So I wonder if the most "correct" way might be to actually store both size and buffer length.
Rename size column to "Allocation" or "Space" and have it populated with the buffer_length.
Add column size and precision to the actual type information so
Type: int[10]
Allocation: 4

Or as in #489 just remove the size column. Since datatype allocation can be checked in manual.

[lelle1234]

I think you are right, these are two different aspects of the type. The logical size related to DDL, and the physical size related to storage. The logical size is irrelevant for certain types such as integer, but I don't think it is worth while to introduce an exception for these. Logical size is likely the more interesting of the two for most people. Den sön 24 jan. 2021 00:20Nils Petzäll <notifications@github.com> skrev:

…

I checked the tests and saw which are failing. Only one actually or "one set". Which i MSSQL, the int column went from 10 to 4. I looked into it, when I figured out the 10, I realized I had done the same thing previously back in #489 <#489>. So I wonder if the most "correct" way might be to actually store both size and buffer length. Rename size column to "Allocation" or "Space" and have it populated with the buffer_length. Add column size and precision to the actual type information so Type: int[10] Allocation: 4 Or as in #489 <#489> just remove the size column. Since datatype allocation can be checked in manual. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#744 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AE2GWEPZ5G7FJT5CGJI2ACTS3NKSBANCNFSM4WPCCRQQ> .