|
Boost : |
From: Kostas Savvidis (kotika98_at_[hidden])
Date: 2021-03-11 11:26:13
> On Mar 10, 2021, at 17:34, Richard Hodges via Boost <boost_at_[hidden]> wrote:
> On Wed, 10 Mar 2021 at 16:16, Niall Douglas via Boost <boost_at_[hidden]>
> wrote:
>> On 10/03/2021 14:13, Ruben Perez via Boost wrote:
>>> I don't think the performance gain you may get from using 1, 2 or 4 byte
>>> integers (if any) is worth it, especially in 64 bit systems.
>>
>> It's not about performance. It's about correctness.
>>
>> It's also about ease of writing code quickly (particularly in environments
> where MySQL is commonly used).
> In almost all applications, "1", 1 and true all mean the same thing.
In C and C++ we have implicit promotion rules, usual arithmetic conversions, and what not.
Headache, yes for sure, but I will conjecture that bringing any SQL integer type, even unsigned, and treating it as int64_t
does not violate any standard and thus is not an issue of correctness.
However, I would like to enquire of the author about the treatment of the following:
1) Section 11.1.4 - Floating-Point Types
SQL allows to specify floating point precision p as FLOAT( p )- do you respect columns with p != 24 or 53?
2) Section 11.1.6 - UNSIGNED is allowed in MySQL even on floating point types - what do you do when you insert into such a column?
3) Section 11.1.3 talks of both DECIMAL and NUMERIC as exact values and MySQL works with
up to 65 decimal digit precision, presumably doing calculations in decimal as well. What is this type mapped into?
4) Section 11.1.6 - Do you need to handle ZEROFILL?
5) Some general comment about Date and Time related stuff?
Thanks,
Kostas
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk