Fix numeric conversion logic

[evertlammerts]

Fixes #115 , #171 and #330

[matthijskooijman]

Thanks for picking this up!

I had a quick glance, looks ok to me (but I am not too familiar with the code). Interesting approach to shift the python int to access the upper 64 bits :-)

I do wonder if the entire numeric parsing code could not be simplified (e.g. the lower 64-bit parsing code for hugeint is pretty similar to the parsing for bigint and other integer types, I wonder if would not make sense to just have a single bit of code that tries longlong first, then unsigned long long and if that still overflows, does the shift for the upper 64 bits (and/or maybe even just parse as huge int always and then cast down to whatever type is expected, but that is probably wrong if no explicit target type is given).

[evertlammerts]

I had a quick glance, looks ok to me (but I am not too familiar with the code). Interesting approach to shift the python int to access the upper 64 bits :-)

One of the hidden gems in Python's C API. It's better than going through an intermediate string.

I do wonder if the entire numeric parsing code could not be simplified (e.g. the lower 64-bit parsing code for hugeint is pretty similar to the parsing for bigint and other integer types, I wonder if would not make sense to just have a single bit of code that tries longlong first, then unsigned long long and if that still overflows, does the shift for the upper 64 bits (and/or maybe even just parse as huge int always and then cast down to whatever type is expected, but that is probably wrong if no explicit target type is given).

Good point. There's a lot of cleanup we could be doing, but we should at least avoid adding to the mess. I've removed some dead code and simplified some paths.