Re: Should casting to integer produce same result as trunc() - Mailing list pgsql-general

From Alban Hertroys
Subject Re: Should casting to integer produce same result as trunc()
Date
Msg-id CAF-3MvNxkJ5REqp+Nqxtsd2LjQ=+gVGeb97F1BCeNhmpw1cBMQ@mail.gmail.com
Whole thread Raw
In response to Re: Should casting to integer produce same result as trunc()  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Should casting to integer produce same result as trunc()  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Should casting to integer produce same result as trunc()  ("Harvey, Allan AC" <HarveyA@OneSteel.com>)
List pgsql-general
On 11 October 2011 15:41, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Alban Hertroys <haramrae@gmail.com> writes:
>> On 11 Oct 2011, at 2:55, Harvey, Allan AC wrote:
>>> My simple understanding of trunc() and casting to an integer says that
>>> there is a bug here.
>
>> Which the type-cast should round to 4380103 and 4380104 respectively.
>> It doesn't:
>
> That's because a cast from float to int rounds, it doesn't truncate.
>
> regression=# select (4.7::float8)::int;
>  int4
> ------
>    5
> (1 row)

I figured it would be something like that. Is that how it's defined in
the SQL standard?

All other programming languages I've come to know truncate floats on
such casts (C, php, python, java, to name a few).
This is probably quite surprising to people used to these languages.

I agree that rounding is the right thing to do. We are probably just
too used to programming languages that truncate instead of round
because it was more convenient to implement it that way at the time.

--
If you can't see the forest for the trees,
Cut the trees and you'll see there is no forest.

pgsql-general by date:

Previous
From: Alban Hertroys
Date:
Subject: Re: Global Variables?
Next
From: Sandro Santilli
Date:
Subject: Re: [postgis-users] Query slow down, never completes