Re: refactoring - share str2*int64 functions

Michaël,

>> For symmetry and efficiency, ISTM that uint16 mul overflow could use uint32
>> and uint32 could use uint64, and the division-based method be dropped in
>> these cases.
>
> Yes, the division would be worse than the other.  What do you think
> about using the previous module I sent and measure how long it takes
> to evaluate the overflows in some specific cases N times in loops?

Given the overheads of the SQL interpreter, I'm unsure about what you 
would measure at the SQL level. You could just write a small standalone C 
program to test perf and accuracy. Maybe this is what you have in mind.

>> I would tend to commit working solutions per type rather than by
>> installment, so that at least all added functions are actually used
>> somewhere, but it does not matter much, really.
>
> I prefer by section, with testing dedicated to each part properly
> done so as we can move to the next parts.

This suggests that you will test twice: once when adding the inlined 
functions, once when calling from SQL.

>> The checking extension is funny, but ISTM that these checks should be (are
>> already?) included in some standard sql test, which will test the macros
>> from direct SQL operations:
>
> Sure.  But not for the unsigned part as there are no equivalent
> in-core data types,

Yep, it bothered me sometimes, but not enough to propose to add them.

> still it is possible to trick things with signed integer arguments.

Is it?

> I found my toy useful to check test all implementations consistently.

Ok.

>>   fabien=# SELECT INT2 '1234512434343';
>>   ERROR:  value "1234512434343" is out of range for type smallint
>>
>> Well, a quick look at "src/test/regress/sql/int2.sql" suggests that
>> there the existing tests should be extended… :-(
>
> We can tackle that separately.  -32768 is perfectly legal for
> smallint, and the test is wrong here.

Do you mean:

  sql> SELECT -32768::INT2;
  ERROR:  smallint out of range

This is not a negative constant but the reverse of a positive, which is 
indeed out of range, although the error message could help more.

  sql> SELECT (-32768)::INT2;
  -32768 # ok

  sql> SELECT INT2 '-32768';
  -32768 # ok

-- 
Fabien.