Re: casts and conversions
От | Tom Lane |
---|---|
Тема | Re: casts and conversions |
Дата | |
Msg-id | 1696.992874112@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: casts and conversions ("Josh Berkus" <josh@agliodbs.com>) |
Ответы |
Re: casts and conversions
|
Список | pgsql-sql |
"Josh Berkus" <josh@agliodbs.com> writes: > And, just to throw a banana peel onto the sidewalk of argument, there is > even a reason to keep things the way they are. [ ... ] > Thus there's a good reason for the database to be indecisive about > float/numeric decisions, and good reason for you to explicitly CAST. Indeed. However, the SQL92 spec has its mind made up: section 6.12 says 1) If the data type of both operands of a dyadic arithmetic opera- tor is exact numeric, then the datatype of the result is exact numeric, [ ... ] 2) If the data type of either operand of a dyadic arithmetic op- erator is approximate numeric, then thedata type of the re- sult is approximate numeric. So it's clear that for spec conformance we should cast numeric to float8 and do the multiply in float math. (Never mind that this could result in loss of precision or even overflow :-( since PG's numerics actually have a wider range of values than float8.) A closely related issue is that SQL92 expects a literal like "1.234" to be considered exact numeric, not approximate, so our initial typing of such literals as float8 is wrong too. We'll have to fix literal processing as well as the float8-vs-numeric-preference issue before we'll have spec-compliant processing of expressions like "numericvar * 1.234". (And yes, there's been lots and lots of discussion about how to do that, too...) regards, tom lane
В списке pgsql-sql по дате отправления: