| Gleb Paharenko 2005-05-28, 7:23 am |
| Hello.
In my opinion MySQL follows the documentation. From:
http://dev.mysql.com/doc/mysql/en/numeric-types.html
"When a floating-point or fixed-point column is assigned a value that
exceeds the range implied by the specified (or default) precision and
scale, MySQL stores the value representing the corresponding end point
of that range."
Don MacAskill <onethumb@onethumb.com> wrote:
> [-- text/plain, encoding 7bit, charset: ISO-8859-1, 75 lines --]
>
>
> I've already opened a support ticket with MySQL on this issue, but
> thought someone here might know the answer, too:
>
>
> Hi there,
>
> I'm trying to make sure I'm not doing something stupid. I'm trying to
> migrate from 4.0 to 4.1, but I'm hitting a snag. I can't find anything
> in the docs to describe what I'm seeing.
>
> MySQL's docs seem to suggest that a column with 'float(5,2)' specifies
> as display width of 5 and a decimal precision of 2. I assumed that the
> 'display width' worked like the other numeric types and would allow
> storing larger values.
>
> On 3.32 and 4.0, this was the case. I was able to store large numbers in
> this float:
>
> mysql> explain testFloat;
> +----------+---------------------+------+-----+---------+-------+
> | Field | Type | Null | Key | Default | Extra |
> +----------+---------------------+------+-----+---------+-------+
> | Floating | float(5,2) unsigned | | | 0.00 | |
> +----------+---------------------+------+-----+---------+-------+
> 1 row in set (0.02 sec)
>
> mysql> insert into testFloat values ('134567.12344321');
> Query OK, 1 row affected (0.00 sec)
>
> mysql> select * from testFloat;
> +-----------+
> | Floating |
> +-----------+
> | 134567.12 |
> +-----------+
> 1 row in set (0.00 sec)
>
>
> After upgrading to 4.1, however, this functionality seems partially broken:
>
> mysql> explain testFloat;
> +----------+---------------------+------+-----+---------+-------+
> | Field | Type | Null | Key | Default | Extra |
> +----------+---------------------+------+-----+---------+-------+
> | Floating | float(5,2) unsigned | | | 0.00 | |
> +----------+---------------------+------+-----+---------+-------+
> 1 row in set (0.00 sec)
>
> mysql> insert into testFloat values ('134567.12344321');
> Query OK, 1 row affected, 1 warning (0.00 sec)
>
> mysql> select * from testFloat;
> +----------+
> | Floating |
> +----------+
> | 999.99 |
> +----------+
> 1 row in set (0.00 sec)
>
>
> I say partially broken, because my existing 4.0 data is fine. In fact, I
> can change an InnoDB table to MyISAM and then back to InnoDB using
> 'alter table' and it retains the proper values.
>
> FYI, this is on both 4.1.11 RPM distro from MySQL and 4.1.10a-1 from Red
> Hat Enterprise 4. Occurs on both x86 and x86_64, RH9 and RHEL4
> respectively.
>
> Any ideas? Is this really an incompatible change that just hasn't been
> documented? Am I missing something obvious? I have a lot of tables I
> expected to behave the same way as they did in prior releases...
>
> Don
>
> [-- application/x-pkcs7-signature, encoding base64, 60 lines, name: smime.p7s --]
> [-- Description: S/MIME Cryptographic Signature --]
>
--
For technical support contracts, goto https://order.mysql.com/?ref=ensita
This email is sponsored by Ensita.NET http://www.ensita.net/
__ ___ ___ ____ __
/ |/ /_ __/ __/ __ \/ / Gleb Paharenko
/ /|_/ / // /\ \/ /_/ / /__ Gleb.Paharenko@ensita.net
/_/ /_/\_, /___/\___\_\___/ MySQL AB / Ensita.NET
<___/ www.mysql.com
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/mysql? unsub...sie.nctu.edu.tw
|