Re: Precision of data types and functions
От | Brandon Aiken |
---|---|
Тема | Re: Precision of data types and functions |
Дата | |
Msg-id | F8E84F0F56445B4CB39E019EF67DACBA21F664@exchsrvr.winemantech.com обсуждение исходный текст |
Ответ на | Re: Precision of data types and functions (Scott Marlowe <smarlowe@g2switchworks.com>) |
Ответы |
Re: Precision of data types and functions
|
Список | pgsql-general |
The Gregorian calendar was established in the 1500's by Pope Gregory, so, no, those dates did not exist. -- Brandon Aiken CS/IT Systems Engineer -----Original Message----- From: Scott Marlowe [mailto:smarlowe@g2switchworks.com] Sent: Friday, September 01, 2006 2:22 PM To: Brandon Aiken Cc: pgsql general Subject: Re: [GENERAL] Precision of data types and functions On Fri, 2006-09-01 at 10:37, Brandon Aiken wrote: > Oh, I'm not saying that MySQL is a full-featured database, nor saying > that I agree with the MySQL philosophy. I don't. That's why I'm trying > to avoid MySQL. > > However PostgreSQL isn't any more accurate with FLOATs than MySQL is. > The ANSI SQL standard for FLOAT is for an inaccurate number. It was > never meant to be accurate, so even though MySQL has a much more liberal > philosophy it's still behaving correctly when it does the math > inaccurately. Which is just like I would expect PostgreSQL or DB2 or > Oracle to do. If you need numeric accuracy and you pick FLOAT for your > field, that *is* the developer's fault. You picked a screwdriver when > you needed a chisel. > > Now, MySQL's design to 9-fill fields when you try to enter a too-large > number is, in fact, stupid on MySQL's part. I consider that silent > truncation. Heck, MySQL lets you create a date on February 31st, or > prior to the year 1500, both of which are obviously nonsensical. What's nonsensical about a date before the year 1500??? it's not like that didn't exist or something.
В списке pgsql-general по дате отправления: