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.
